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Sobre o autor 


Meu nome é Jhones dos Santos Clementino, sou 
apaixonado por programação desde os 17 anos quando 
descobri que os softwares, games e sites eram 
desenvolvidos através de alguma linguagem de 
programação - essa descoberta mudou minha vida. 
Comecei a me interessar por esses assuntos cada vez 
mais e mais porque achava incrível uma sequência de 
código fazer algo tão útil e interessante como os jogos, 
por exemplo, isso é fascinante! =D 


Sou formado em Ciência da Computação pela 
Universidade Paulista - UNIP e trabalho com 
desenvolvimento de sistemas Web desde 2009, quando 
ocorreu meu primeiro contato com o PHP. Desde aquela 
época fui me dedicando a aprender mais e mais com 
cursos online, tutoriais, livros e apostilas, e meu foco tem 
sido a Web porque são tecnologias que estão em 
constante evolução. Pretendo ampliar mais esse leque de 
plataformas e também dedicar-me ao mobile para projetos 
futuros que tenho em mente. 


Meu primeiro contato com o Zend Framework foi em 2013 
quando ele já estava na versão 2. Entrei para área de Tl 
de um banco, onde estavam fazendo um portal interno 
completamente em ZF2, foi então que encontrei a perfeita 
oportunidade para aprender a utilizar o ZF2 e gostei muito 
da sua forma explícita de definir a lógica. Ha quem critique 
e ha quem goste do ZF, eu particularmente gosto muito e 
posso dizer que é um dos meus frameworks preferidos. 


Quando possuo um tempo livre gosto de fazer alguma 


coisa que tire a minha atenção do mundo virtual por algum 
tempo, então gosto de sair, desenhar e até mesmo cantar 
(vamos deixar isso para uma outra hora, OK? Rs). Bom, 
meu amigo, esse é um resumão de quem sou eu. 


Prefácio 


Desde o lançamento do Zend Framework, a comunidade 
Zend tem crescido cada vez mais. Conforme a tecnologia 
e os anos foram avançando, tornou-se essencial a 
agilidade na entrega de novas aplicações, desde sites 
simples a e-commerces, portais e APIs. Contudo, a Zend 
ainda não possuía um framework enxuto para um 
desenvolvimento mais rápido de aplicações, focado em 
encontrar uma solução para o problema. Foi então que a 
Zend desenvolveu o que todos mais aguardavam, um 
microframework. 


Zend Expressive é um microframework criado pela Zend 
com o objetivo de atender desde as demandas mais 
simples para criação de aplicações de minima escala a 
APIs e aplicações mais complexas de alta escala. 


Hoje em dia, o numero de aplicações distribuídas esta 
cada vez maior. Entende-se por aplicações distribuídas 
aquelas que funcionam de forma independente, ou seja, 
sem serem restritas a apenas um tipo de plataforma. Zend 
Expressive vai nos ajudar a desenvolver uma API ou, 
como muitos chamam, Web Service, que funcionará de 
forma independente para que qualquer aplicação client 
possa fazer a comunicação com a API. 


Não se preocupe se no momento você não estiver 
entendendo muito bem, vamos falar muito sobre o Zend 
Expressive no decorrer deste livro, afinal ele é o 
protagonista desta obra. 


Este livro é indicado para os desenvolvedores que estão 


iniciando no mundo dos frameworks/microframeworks e 
também para os programadores mais experientes que já 
possuem um conhecimento mais avançado das 
tecnologias voltadas para a Web com o PHP. 


Para este livro, é necessário que o leitor tenha o 
conhecimento básico sobre PHP 7 e Programação 
Orientada a Objetos. Ambos são indispensáveis pois 
serão utilizados com frequência durante o 
desenvolvimento do nosso projeto. 


O projeto e os exemplos podem ser desenvolvidos 
utilizando: 


e S.O (Sistema Operacional): Linux Ubuntu 16.04 ou 
superior com suporte a PHP 7 / Windows 7 ou 
superior / MacOS com suporte a PHP 7; 

e Servidor: Apache2 ou Nginx; 

e Linguagem de programação: PHP 7.2 ou superior; 

e IDE: PHPStorm (Vocé pode utilizar qualquer outra 
IDE de sua preferéncia como: Eclipse, Netbeans, 
Sublime, Notepad++ entre outras); 

e Client HTTP para fazer as requisições da API: 
Postman ou outro client de sua preferéncia como: 
Advanced REST client, SOAP UI, entre outros; 

e Gerenciador de dependéncias: Composer na versao 
1.6.5 Ou superior. 


Os exemplos estão no repositório do GitHub: 
https://github.com/jhones/livro-zend-expressive/. 


Caso o leitor possua dúvidas, críticas, sugestões ou 
correções, poderá entrar em contato através do e-mail: 
jhones.developer@gmail.com ou pelo Linkedin: 


https://www.linkedin.com/in/jnones-dos-santos-clementino- 
91a90256/. 


No decorrer deste livro, vamos abordar diversos temas 
envolvendo APIs, microsservicos e o microframework 
Zend Expressive, que foi lançado antes do Zend 
Framework 3. Vamos abordar também como fazer a 
integração com o ORM _ Doctrine, falaremos de 
middlewares e muito mais. Por fim, vamos desenvolver 
uma API bem simples com o Zend Expressive e PHP 7 
em que vamos realizar um CRUD de tipos de usuários, e 
de mensagens. Nós vamos aplicar alguns dos 
componentes do Zend Framework 3 para que 0 
conhecimento adquirido seja fixado da melhor maneira 
possível. Se você está preparado para iniciar nossa 
jornada rumo ao mundo dos microframeworks e APIs 
então siga em frente aos próximos capítulos. Bom estudo! 


CAPÍTULO 1 
Introdução 


Hoje em dia, existem diversos frameworks dos mais 
variados tipos e complexidade. Com o surgimento de 
frameworks full stack, o trabalho dos desenvolvedores se 
tornou algo mais simples e eficaz, afinal esses 
frameworks trazem consigo um grande conjunto de 
bibliotecas que visam facilitar as tarefas do nosso dia a 
dia. 


Um framework full stack é um conjunto de componentes, 
bibliotecas e conceitos que seguem uma estrutura bem- 
definida que facilita a vida do desenvolvedor durante o 
desenvolvimento de um projeto. Já um microframework 
também é um conjunto de componentes, bibliotecas e 
conceitos, porém com uma estrutura minimalista capaz de 
criar aplicações de minima escala, APIs e outras. No 
capitulo 2 você encontrará mais detalhes de cada tipo, 
exemplos, vantagens e desvantagens e quando usar 
framework full stack ou microframework, não se preocupe. 


Uma das grandes vantagens do framework full stack é a 
quantidade de bibliotecas fornecidas, dentre as quais 
podemos citar: validações, conexões com banco de 
dados, filtros, forms, autenticação, paginação. Mas 
Jhones, só existe vantagem em utilizar framework full 
stack? A resposta, meu amigo, é "nao"! 


Tudo o que conhecemos hoje possui vantagens e 
desvantagens. Uma das grandes desvantagens desse tipo 
de framework é exatamente a quantidade de bibliotecas 


que são instaladas com o core do framework, pois nem 
tudo o que será instalado realmente será utilizado pelo 
desenvolvedor. 


Um bom exemplo de um framework desse tipo é o próprio 
Zend Framework 1 e 2. Quando fazíamos a instalação do 
ZF, todo o framework era instalado, ou seja, todas as 
bibliotecas eram instaladas sem necessidade junto com o 
framework. Isso acabava afetando a performance do 
sistema, por se tornar muito pesado com todas as 
bibliotecas instaladas. Para entender melhor, imagine o 
seguinte cenário: você acessa um site que carrega 
inúmeras imagens de diversos tamanhos junto com o 
carregamento inicial da página; não demora muito para 
você notar que a página está lenta. Por que isso 
acontece? A resposta é bem simples, o site carregou 
todas as imagens sem necessidade. Em vez de carregar 
apenas algumas imagens e colocá-las no cache, o site 
carrega todas sem nenhum tipo de tratamento. O exemplo 
citado parece absurdo, mas é exatamente o que acontece 
com o Zend Framework. Ao baixarmos e instalarmos ele 
virá com todas as bibliotecas e, consequentemente, 
afetará a performance do sistema. 


Felizmente, no ZF3, obtivemos grandes melhorias, entre 
as quais podemos citar: a separação dos componentes do 
core do framework, ou seja, você instala somente o que 
realmente for utilizar em sua aplicação, diferentemente do 
seu antecessor. O Zend Framework 3 está mais robusto: 
se antes tínhamos todo o framework instalado com todos 
os seus componentes agora a Zend focou na 
reusabilidade e interoperabilidade. Ao baixá-lo, só os 
principais componentes são instalados junto com o 
framework a fim de assegurar sua correta execução e 


funcionamento como: zend-mvc , zend-eventmanager , 
zend-modulemanager , zend-servicemanager , zend-router , 
entre outros. Além disso, ele possui suporte e 
compatibilidade para o desenvolvimento utilizando o PHP 
f. 


Outro ponto bem importante que vale a pena ressaltar é 
quanto à performance. O framework executa 4 vezes mais 
rápido do que o seu antecessor, Zend Framework 2. Vale 
ressaltar também que ele não possuia um 
microframework para a criação de APIs ou aplicações de 
mínima escala, e a fim de resolver esse problema a Zend 
criou o Zend Expressive. Com esse nosso camarada 
podemos facilmente criar APIs seguindo os conceitos da 
PSR-7 e PSR-15, bem como fazer a integração de outros 
componentes tanto da Zend quanto bibliotecas de 
terceiros. Por exemplo, se você não gosta ou não está 
habituado a trabalhar com o modelo de rotas Zend Router, 
não tem problema, você pode usar o Aura Router ou Fast 
Route. Tudo bem, legal essa parte, mas é só isso que ele 
pode oferecer”? A resposta para essa pergunta, meu caro 
amigo, também é "nao"! 


Zend Expressive está muito mais além do que podemos 
imaginar e conheceremos a fundo mais desse incrível 
microframework nos próximos capítulos. Para 
entendermos um pouco sobre o conceito de 
microframeworks, precisamos entender o motivo que 
levou ao seu surgimento. 


Por que usar microframeworks 


Com o passar dos anos, a necessidade por serviços cada 
vez mais ágeis foi crescendo de tal forma que os 


frameworks precisavam atender a essa demanda de 
forma mais rápida e eficaz. Assim, pouco a pouco, foram 
surgindo sistemas baseados em serviços ou, como 
chamamos, APIs (Application Programming Interface) e, 
consequentemente, novos frameworks menos 
engessados com o intuito de facilitar a criação de APIs: os 
famosos microframeworks. 


Muitas empresas e comunidades mantenedoras de seus 
frameworks começaram a acompanhar a nova evolução 
da Era das APIs, logo, foram surgindo diversos 
microframeworks como: Slim, Silex (já descontinuado), 
Lumen, Zend Expressive, entre outros tantos existentes. É 
simples trabalhar com esses microframeworks? Como 
posso conhecer um pouco melhor cada um deles? A 
resposta está logo a seguir. Veja uma pequena lista das 
características de cada um dos microframeworks citados 
anteriormente para ver para que serve cada um deles e 
no que eles podem ajudá-lo: 


e Zend Expressive - é um microframework para 
criação de APIs e aplicações pequenas. Foi 
desenvolvido pela Zend, possui compatibilidade com 
o PHP 7 e tem uma excelente performance. 

e Slim - é um microframework que nos ajuda a 
desenvolver APIs de maneira muito rápida e fácil. 
No mundo das APIs em PHP, é um microframework 
bastante conhecido. 

e Silex (já descontinuado) - é um microframework 
para criação de APIs e foi desenvolvido por Fabien 
Potencier, mesmo criador do Symfony, logo o Silex é 
baseado no próprio Symfony e possui uma boa 
performance. 


e Lumen - é um microframework baseado em Laravel 
para a construção de APIs e sua comunidade tem 
crescido muito devido à facilidade em sua utilização 
e a grande quantidade de pacotes disponíveis. 


Vale ressaltar que a escolha de um framework ou 
microframework vai muito além de qualidades técnicas, 
complexidade e performance: depende muito do projeto 
que será desenvolvido e até mesmo do gosto da pessoa. 
Eu, particularmente, prefiro as coisas mais explícitas 
mesmo que seja um pouco mais trabalhoso; mesmo 
assim, a escolha sempre dependerá do projeto a ser 
desenvolvido e, principalmente, do prazo a ser cumprido. 


Muitos desenvolvedores que migram constantemente 
entre frameworks full stack e microframeworks, seja por 
aventura e conhecimento, seja devido ao dia a dia no 
trabalho, notarão que as coisas no Zend Framework / 
Zend Expressive são mais explícitas e devem ser 
definidas. Ou seja: vai criar uma action? Tem que defini-la 
no arquivo de configuração. Vai criar um serviço? Tem 
que defini-lo no arquivo de configuração. E sera assim 
praticamente com boa parte do que você for criar no 
framework. 


Mas você pode estar se perguntando: qual a diferença 
entre Zend Framework e Zend Expressive? A diferença é 
que o Zend Framework é um framework full stack com 
uma estrutura mais complexa para o desenvolvimento de 
aplicações mais robustas e com mais recursos. Já o Zend 
Expressive é um microframework para o desenvolvimento, 
desde APIs e aplicações mais simples, até aplicações 
mais complexas. São notáveis os esforços da Zend para 
tornar o framework e o microframework ferramentas de 


desenvolvimento cada vez melhores e ela está 
percorrendo grandes caminhos para alcançar esse 
objetivo. Não podíamos iniciar este livro sem apresentar a 
essência do conhecimento por trás de toda essa 
tecnologia. 


Sem dúvidas é um microframework que veio para agregar 
valores e conhecimentos principalmente no mundo das 
APIs. Nos próximos capítulos, veremos muito do Zend 
Expressive e do que ele é capaz de nos proporcionar para 
tornar o desenvolvimento de APIs e microsserviços mais 
agil. 


CAPÍTULO 2 
Frameworks full stack vs. 
microframeworks 


Neste capitulo, vamos abordar diferenças e 
características de frameworks full stack œ 
microframeworks, quais as vantagens e desvantagens de 
cada um dos tipos, exemplos e quando utilizar um ou 
outro. É importante conhecer as diferenças entre eles 
para que não haja confusão, então siga em frente! 


2.1 Framework full stack 


Framework full stack é um conjunto completo de 
bibliotecas disponibilizadas para atender as mais variadas 
necessidades do dia a dia do desenvolvedor, desde a 
criação de views, MVC (Model View Controller), 
paginação, abstração da camada de banco de dados, 
filtros, validações e entre outras diversas bibliotecas. Para 
que você entenda melhor, um conjunto de classes e 
métodos formam uma biblioteca; e um conjunto de 
bibliotecas, seguindo alguns padrões, conceitos e 
arquiteturas bem-definidas e testadas, formam um 
framework. 


MVC (MobeL View CONTROLLER) - é um padrão de 
arquitetura de software que visa separar a aplicação 
em 3 camadas: Model, responsável pela regra de 
negócio da aplicação, é quem realiza a interação com 
o banco de dados; View, responsável por apresentar 
as informações na tela para o usuário; Controller, 
responsável pela mediação entre as camadas de 
Model e View, ou seja, essa camada obtém os dados 
do banco de dados através da Model e repassa esses 
dados para a camada da View. 


Views - Nada mais são do que páginas de exibição 
de informações, podendo ser em PHP, HTML, 
XHTML, PHTML etc. 





Como mencionado anteriormente, tudo o que 
conhecemos hoje em dia possui suas vantagens e 
desvantagens. Vamos conhecer então algumas vantagens 
e desvantagens dos frameworks full stack: 


Vantagens 


e Conjunto completo de bibliotecas - lembre-se de 
que uma biblioteca é um conjunto de classes e 
métodos que seguem uma determinada lógica para 
solucionar um determinado problema, logo 
bibliotecas de: validação e filtragem de dados, 
autenticação de usuários, envio de e-mails, criação 
de logs, paginação, estrutura MVC, dentre muitas 
outras, já são instaladas com o framework full stack. 
Com isso, o trabalho do desenvolvedor torna-se 


mais simples, já que não há muitos motivos para 


vasculhar a internet atrás de uma biblioteca 
compativel com a necessidade exigida pelo projeto. 


e Estrutura MVC definida - a estrutura padrão para a 
criação do projeto seguindo o modelo MVC já vem 
definida e bem testada, facilitando na criação da 
lógica do projeto. Quem já trabalhou com MVC 
completamente do zero sabe que não é tão 
complicado, mas é um pouco trabalhoso. Já com a 
mesma estrutura definida pelo próprio framework 
fica bem mais simples e muito menos trabalhoso de 
se criar a lógica. 


Desvantagens 


e Nem todas as bibliotecas instaladas com o 
framework serão utilizadas - apesar de ser uma 
grande vantagem, ter todas as bibliotecas instaladas 
com o framework acaba se tornando uma 
desvantagem também, pois nem todas as 
bibliotecas instaladas serão utilizadas em um projeto 
afetando a performance do sistema. É o mesmo que 
instalar um framework full stack para criar apenas 
um site simples que não requer tanta tecnologia. 

e Alta curva de aprendizagem - um framework full 
stack requer um estudo mais aprofundado para que 
se domine com sucesso seus recursos e 
funcionalidades, e por ser maior e mais completo, 
estudar a documentação completa demanda muito 
tempo que hoje em dia é tão raro quanto água no 
deserto. 

e Maior tempo e complexidade para criar novas 
funcionalidades - se estudar toda a documentação 
de um framework full stack demanda tempo, 


também acontece de alguns recursos levarem muito 
mais tempo para serem implementados com 
sucesso, principalmente se a documentação não for 
tão boa. 


Características 


Cada framework desenvolvido possui características 
peculiares que podem atender ou não as necessidades do 
desenvolvedor. Por isso, antes de optar por algum 
framework e incorpora-lo ao projeto que sera 
desenvolvido, você deve levar em consideração as suas 
características. Por exemplo, algumas características 
podem ajudar você a decidir na tomada de decisão no 
momento da escolha de um framework são: 


e Performance - a performance do framework para 
executar uma determinada ação é boa o suficiente 
para atender ao projeto que será desenvolvido”? 

e Integração de bibliotecas de terceiros ao 
framework - é fácil integrar bibliotecas de terceiros 
ao framework ou requer um custo a mais de mão de 
obra? 

e Criação de recursos - a criação de recursos como: 
rotas, páginas, logs, conexões com banco de dados, 
validações, formulários, autenticação e entre outros 
é complexa ou não requer tanto esforço”? 

e Configurações - definir as configurações é claro o 
suficiente para o desenvolvedor e toda a equipe”? 

e Baixo acoplamento - um projeto desenvolvido no 
framework pode ser incorporado facilmente em 
outros, sem muito trabalho, ou sua arquitetura é 
muito restrita e só pode ser incorporada a outros 
projetos desenvolvidos com o mesmo framework? 


e Testes do framework - o framework está testado o 
suficiente para ter uma boa cobertura de testes que 
garante o funcionamento estável? 

e Documentação - a documentação é bem escrita e de 
fácil entendimento e compreensão ou você tem que 
ficar caçando agulha no palheiro? 


Essas características devem ser analisadas para que, em 
um futuro próximo, não se tenha uma grande dor de 
cabeça, seja por problemas de performance, flexibilidade 
e, nos casos mais extremos, estar utilizando um 
framework que será ou foi descontinuado. Tivemos esse 
problema na empresa em que trabalho. Tínhamos varios 
sistemas desenvolvidos em Silex e, em um belo dia, 
vimos que ele foi descontinuado. Nós tínhamos duas 
opções: 


1. Continuar utilizando o Silex sem ter suporte do 
desenvolvedor e correr o risco de o sistema ficar 
defasado e completamente ultrapassado, ou 

2. Investir custo e mão de obra para migrar pouco a 
pouco todos os sistemas para um outro framework 
que atenda todas as necessidades. 


Felizmente, optamos por fazer a migração para um novo 
framework; no caso da empresa, o Symfony 4 foi o 
escolhido. Então, antes de escolher o framework para 
desenvolver o seu projeto, verifique o máximo que puder 
as informações e características, veja se o framework não 
corre o risco de ser descontinuado, acompanhe as 
releases do projeto etc. para que você não tenha um 
problema parecido com o que tivemos na empresa, OK? 


Exemplos de frameworks full stack para PHP 


e Zend Framework - é um framework que possui uma 
grande variedade de bibliotecas desenvolvidas pela 
própria Zend e é bastante flexível pois é fácil integrar 
bibliotecas de terceiros ao projeto. É indicado para a 
criação de projetos de nível intermediário a 
avançado, pois a sua estrutura complexa se torna 
inviável em sistemas muito simples, devido à sua 
curva de aprendizagem e, principalmente, ao 
tamanho do framework (todas as bibliotecas serão 
instaladas e nem todas serão utilizadas, e isso 
acaba afetando a performance do projeto). 


e Symfony - é um framework desenvolvido pela 
SensioLabs e hoje é um dos mais utilizados dentro 
da comunidade PHP, assim como o Zend 
Framework. O Symfony também possui uma grande 
variedade de bibliotecas desenvolvidas pela 
SensioLabs e também é bastante flexível quanto a 
utilização de bibliotecas de terceiros. É indicado 
para a criação de aplicações simples até as mais 
complexas, pois a partir do Symfony 4 pode-se fazer 
a instalação mínima sem ter toda a estrutura 
complexa do framework, o que o torna mais leve, 
dependendo do projeto que será desenvolvido. 


y 


e Laravel - é um dos frameworks que conquistou 
muitos desenvolvedores nos últimos anos e sua 
comunidade cresceu muito devido a sua facilidade 
de instalação, configuração e pela sua 
documentação. É indicado desde os projetos mais 
simples até os mais complexos, pois sua estrutura é 
de fácil entendimento e não demora muito para criar 

um projeto em Laravel. Também é um framework 


~ 


flexível quanto à instalação de bibliotecas de 


terceiros, porém é necessário um conhecimento de 
Facades para utilizar com mais coesão os recursos 
do framework. 


2.2 Microframework 


Pode-se entender como microframework um conjunto 
mínimo de funcionalidades que possam atender a 
determinada necessidade. Ou seja, um microframework é 
voltado para solucionar apenas um determinado 
problema, como criação de APIs, templates e entre 
outros. Não é necessário termos toda a estrutura 
complexa de um framework full stack para a criação de 
um projeto de API, por exemplo. A estrutura mínima 
concedida pelo microframework já é o suficiente. Está 
confuso? Não se preocupe, na seção Quando utilizar 
framework full stack ou microframework você poderá ver 
uma tabela comparativa entre frameworks full stack e 
microframeworks. 


Assim como os frameworks full stack, os microframeworks 
também possuem as suas vantagens e desvantagens. 
Vamos ver algumas delas a seguir: 


Vantagens 


e Baixo nível de complexidade - a estrutura definida 
é mais simples e, consequentemente, o 
desenvolvimento dos recursos e lógica são algo 
muito mais fácil do que em uma estrutura complexa 
como a de um framework full stack. 


e Baixa curva de aprendizagem - por ser menor e 
possuir uma estrutura minimalista, a curva de 
aprendizagem é algo muito baixo, pois não requer 
uma leitura bem aprofundada na documentação 
para começar o desenvolvimento. 


e Performance - como são instalados somente o 
necessário para garantir o funcionamento do 
microframework, a sua performance é maior que a 
de um framework full stack, já que temos apenas o 
necessário e o essencial para começar o trabalho. 


e Agilidade na criação de aplicações de mínima e 
alta escala - desenvolver com um microframework é 
algo muito mais rápido devido ao fato de sua curva 
de aprendizagem ser extremamente baixa. Com 
isso, as aplicações ficam prontas em menor tempo 
e, Claro, com menor custo também. 


Desvantagens 


e Encontrar um recurso ou biblioteca compatível 
pode ser trabalhoso - às vezes, pode ocorrer de 
algumas bibliotecas não serem compatíveis com a 
estrutura do microframework, principalmente se a 
estrutura teve uma mudança radical. Encontrar 
alguma biblioteca similar ou genérica pode exigir 
tempo e trabalho consideráveis. 


e Alguns microframeworks podem ter 
documentação escassa - já encontrei na internet 
microframeworks cuja documentação era 
extremamente escassa e, para entender um 
determinado componente, tive que procurar muito 


em nossos queridos pais Google e Stack Overflow. 
Já houve casos em que o único modo para conhecer 
melhor era o famoso debug do código, imagine 
quanto tempo seria economizado se tivesse uma 
boa documentação”? Muito tempo! 


Características 


No momento de optar pelo microframework para o 
desenvolvimento de um projeto, também é importante 
observar e atentar-se às características de cada um. 
Vamos verificar a seguir algumas caracteristicas que 
podem ajudar você a decidir qual microframework utilizar: 


Complexidade - a estrutura do microframework que 
você está analisando é mais ou menos complexa do 
que outros a serem analisados”? 

Performance - é performático o suficiente para o 
projeto a ser desenvolvido”? 

Implantação - é fácil de ser implantado em outros 
ambientes, como: ambientes de desenvolvimento, 
de homologação, de testes e de produção”? Requer 
muito tempo para fazer essa implantação ou é algo 
rápido? 

Bibliotecas - existem bibliotecas compatíveis que se 
adequam à estrutura do microframework e com o 
que deverá ser desenvolvido? Ou você terá que 
perder um certo tempo em busca de algo compatível 
e/ou mais genérico”? 

Documentação - a documentação é bem escrita e de 
fácil entendimento e compreensão ou é escassa de 
fazer você chegar ao ponto de debugar o código 
para entender seu funcionamento? 


Exemplos de microframeworks para PHP 


e Zend Expressive - o protagonista deste livro foi 
desenvolvido pela Zend, e possui o objetivo de 
facilitar o desenvolvimento de APIs e aplicações 
simples ou até mesmo de aplicações complexas 
sem haver a necessidade de ter uma estrutura tão 
bem-definida e complexa quanto a do Zend 
Framework. Além disso, a documentação é muito 
boa e também possui uma excelente flexibilidade, 
permitindo a instalação de bibliotecas de terceiros. 


e Slim - é um dos primeiros microframeworks com que 
trabalhei para desenvolver uma API e sua estrutura 
é bastante simples e quase não requer muito estudo 
para iniciar o desenvolvimento; realmente é simples 
e bastante flexível. 


e Silex (já descontinuado) - como mencionado 
anteriormente, o Silex foi desenvolvido pelo mesmo 
criador do Symfony e sua estrutura também é muito 
simples e muito fácil de ser compreendida, além 
disso, era compatível com muitas bibliotecas e a 
documentação não era escassa. 


e Lumen - desenvolvido pelo criador do Laravel, 
possui uma estrutura bem simples e também não é 
muito demorado para começar a desenvolver com 
ele. Criar APIS com ele é bem rápido e nao 
demanda muito tempo de estudo, pois sua 
documentação é muito boa. 


2.3 Quando utilizar framework full stack ou 
microframework 


Provavelmente você deve estar se perguntando: Jhones, 
como decido qual utilizar? Primeiramente, você tem que 
identificar qual o tipo de problema que deverá ser 
solucionado, ou seja, depende do tipo de projeto que 
deverá ser desenvolvido. 


Por exemplo, se o projeto for apenas para fornecer 
informações por meio de consultas rápidas, como uma 
consulta rápida pelo nome de uma pessoa, ou CEP, ou 
até mesmo verificar o score de uma pessoa no SPC 
(Serviço de Proteção ao Crédito), a melhor escolha seria 
um microframework, já que a estrutura minimalista dele 
lhe fornece maior facilidade do que um framework full 
stack. Agora, se você for desenvolver um e-commerce ou 
um portal mais complexo, por exemplo, um framework full 
stack seria a melhor opção. Para melhor entendimento, 
veja a seguir uma comparação entre framework full stack 
e microframework: 


Frameworks full stack 


e Quando usar: indicado para projetos mais extensos, 
complexos que requerem mais tecnologia e uma 
estrutura mais definida. 

e Estrutura: completa e mais complexa. 

e Tipos de aplicações: portais, e-commerces, CMS e 
dentre outros tipos de aplicações que requerem 
mais tecnologia. 

e Exemplos: Zend Framework, Symfony, Laravel. 


Microframeworks 


e Quando usar: indicado para projetos mais simples 
ou que atendam a uma determinada demanda. 
Estrutura: minimalista e mais simples. 

Tipos de aplicações: APIs, projetos mais simples 
que não requerem uma estrutura bem-definida 
quanto a de um framework full stack. 

e Exemplos: Slim, Silex (já descontinuado), Zend 
Expressive, Lumen, Twig. 


E importante ressaltar que não existe uma regra 
específica que nos obrigue a utilizar um framework full 
stack para desenvolver uma API, ou um microframework 
para desenvolver uma aplicação mais complexa. O que 
existe são conceitos que se aplicam a um determinado 
projeto para que seja mais fácil escolher com qual dos 
dois tipos trabalhar. Lembre-se de que o tipo de 
framework e qual utilizar dependerá de dois fatores 
extremamente importantes: projeto e prazo. 


Então, não se esqueça: microframeworks para criação de 
APIs, microsserviços ou até mesmo aplicações de mínima 
ou alta escala; e framework full stack para projetos mais 
extensos e complexos como portais, e-commerces, CMS 
etc. Também não deixe de levar em consideração as 
vantagens, desvantagens e características de cada 
framework full stack ou microframework no momento da 
escolha. 


Conclusão 


Neste capítulo, vimos o que é um framework full stack e o 
que é um microframework, juntamente com algumas de 


suas vantagens e desvantagens. Vimos também 
exemplos de frameworks full stack e exemplos de 
microframeworks, e ainda vimos um comparativo entre 
ambos para explicitar algumas diferenças e justificar por 
que utilizar determinado tipo ou outro. Como foi 
mencionado, a escolha de um framework ou 
microframework depende muito de dois fatores muito 
importantes: projeto e prazo. Foi citado um exemplo real 
do que aconteceu na empresa em que trabalho para que 
você pudesse ter a visão de como a escolha cautelosa é 
um ponto vital antes de desenvolver qualquer projeto. 


No próximo capítulo entenderemos sobre SOAP, REST, 
RESTful e API. Veremos brevemente alguns pontos 
importantes sobre esses termos, quais são suas 
aplicabilidades em nosso dia a dia e muito mais. Vamos 
nessa! 


CAPÍTULO 3 


Explorando APIs, SOAP, REST e 
RESTful 


Não ha como falarmos de APIs sem conhecermos parte 
da história da Web, seus conceitos, suas definições, seus 
funcionamentos e os componentes de uma API. E 
exatamente isso que veremos logo a seguir. 


3.1 API (Application Programming Interface) 


API (Application Programming Interface), ou Interface de 
Programação de Aplicativos em português, é um conjunto 
de padrões e rotinas bem-definidas para atender as 
necessidades de uma empresa em fornecer dados 
específicos para aplicações externas. Resumidamente, 
uma API é criada para que outras aplicações possam 
fazer a comunicação independentemente da plataforma 
para obter os resultados de acordo com a requisição. 


Uma API contém inúmeros serviços que fornecem dados 
de acordo com o que for requisitado, por exemplo: uma 
API que fornece dados meteorológicos da situação 
climática do nosso pais poderá conter serviços de 
temperatura, medição da qualidade do ar, medição de 
raios UV (ultravioleta) dentre muitos outros. O cliente que 
solicitar a requisição poderá ter acesso a todos os 
serviços ou apenas alguns deles, isso depende do tipo de 
permissão que a API implementa ou disponibiliza para os 
usuários. 


Empresas do mundo inteiro começaram a utilizar APIs 
para que houvesse mais compatibilidade com o maior 
número de plataformas possíveis e graças a elas, 
desenvolvemos apenas uma unica vez para uma 
determinada plataforma e os clientes apenas fazem a 
comunicação. Uma vez que o cliente pode ser de 
qualquer tipo de plataforma como desktops, TVs, web, 
mobile, apenas será responsável por fazer a requisição ao 
serviço sem se preocupar com a lógica que está na API. 


Você pode estar se perguntando: toda API é igual e serve 
para atender a mesma necessidade” A resposta é "nao" 
para ambas as perguntas, cada API atende um 
determinado problema. Lembre-se que uma API tem por 
objetivo fornecer serviços para que aplicações externas 
possam obter informações específicas, seja para mostrar 
ao usuário ou para tomar uma determinada decisão 
dentro da aplicação. 


3.2 SOAP (Simple Object Access Protocol) 


SOAP (Simple Object Access Protocol), ou Protocolo 
Simples de Acesso a Objetos em português, é um 
protocolo de comunicação para troca de mensagens 
baseado em XML (eXtensible Markup Language) 
permitindo que uma ou mais aplicações se comuniquem 
através do protocolo HTTP. 


Se você já trabalhou com XML então poderá pular essa 
pequena introdução. Basicamente, XML é uma linguagem 
de marcação semelhante ao HTML, com a diferença de 
que é você que define a estrutura que seu arquivo XML 


poderá ter. Há muitos exemplos de XML na internet e 
inclusive há exemplos de XML usados para carregar 
configurações da aplicação. 


Para quem não conhece, o protocolo HTTP (Hypertext 
Transfer Protocol), ou Protocolo de Transferência de 
Hipertexto em português, simplesmente é a base da 
comunicação na Web. Sabe aquele seu site preferido que 
você acessa ao digitar na barra de endereço de seu 
navegador”? Pois bem, quando você digita o endereço do 
site no navegador, ele está fazendo uma comunicação 
HTTP para troca de informações, em que você solicita o 
acesso ao site e o servidor do site verifica a requisição e 
permite a transferência dos dados da página para o seu 
dispositivo (computador, notebook, smartphone, TV, 
dentre outros) que resulta na pagina completamente 
montada para voce visualizar. 


Hoje em dia, ha muitas empresas que utilizam o SOAP 
para fazer a comunicação entre as aplicações internas e 
externas por ele ser um protocolo bem-definido. 


Você pode estar se perguntando: mas como implemento o 
SOAP em meu projeto de API em PHP? Primeiramente, 
você precisa instalar a extensão do PHP: phpz.2-soap OU 
php7.1-soap OU php5.6-soap . Esse módulo traz consigo 
algumas classes e uma série de métodos que você 
deverá utilizar para que sua API funcione por meio do 
modelo SOAP. Não será descrito detalhadamente como 
criamos uma API em SOAP, mas é preciso entender que 
o SOAP existe e é importante conhecer sobre esse 
protocolo. Principalmente se você vai iniciar com o 
desenvolvimento de APIs e até mesmo para realizar 
manutenção em APIs existentes ou somente fazer a 


comunicação com elas. 


O funcionamento do SOAP é bastante simples, podendo 
ocorrer de 3 métodos ou padrões possíveis: GET, POST € 
soap . Basicamente, O GET eo post são métodos HTTP 
e seu funcionamento é o mesmo, ou seja, o método GET 
é utilizado para obter dados, por exemplo, obter os dados 
de um determinado usuário. O método post é utilizado 
para fazer a gravação das informações no banco de 
dados, por exemplo, salvar os dados do cadastro de um 
usuário. Já o soap é como O POST , porém com a 
diferença de que as requisições efetuadas devem possuir 
o formato xm. , OU Seja, isso significa que todas as 
requisições serão sempre no formato XML. Para entender 
melhor o funcionamento entre as aplicações cliente e uma 
API SOAP, veja a imagem a seguir: 
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Figura 3.1: Funcionamento de API SOAP 
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O esquema de comunicação não é complicado. 
Basicamente, a aplicação cliente descobre o serviço, faz a 
requisição e obtém a resposta do serviço. Não é do 
escopo deste livro entrar em detalhes aprofundados sobre 
o funcionamento detalhado de cada parte da estrutura de 
uma mensagem SOAP; para mais informações sobre o 
funcionamento do SOAP, você pode acessar o link 
https://www.devmedia.com.br/web-services/28/3/, ou 
conferir nas referências deste mesmo livro. 


Mas por que será que o SOAP é um padrão 
extremamente utilizado no mundo inteiro? Quais são as 
suas vantagens e desvantagens? 


Vantangens 


e Funcionamento independente da plataforma - 
não fica amarrado a apenas uma plataforma. Uma 
API em SOAP pode ser consumida e utilizada por 
todos os tipos de clientes (plataformas) sem a 
necessidade de fazer o desenvolvimento de código 
diferente para cada tipo de plataforma. 


e Alta interoperabilidade - a interoperabilidade com 
diversas plataformas é algo que funciona muito bem 
com SOAP, pois o modelo padrão de envio e 
resposta definidos (que é o xm ) facilita para que se 
tenha uma excelente comunicação entre as 
plataformas. 


e Fácil interpretação - é muito mais fácil 
interpretarmos um arquivo que possui uma estrutura 
em xm. do que analisar uma resposta em JSON 
(JavaScript Object Notation), por exemplo. 


Desvantagens 


e Possui um overhead a mais - além do cabeçalho 
da requisição HTTP, pode-se ter um cabeçalho 
SOAP com as mesmas informações, ou seja, 
causando uma certa redundância de informação. 


e É um pouco mais trabalhoso de ser 
implementado, dependendo da linguagem de 
programação - cada linguagem de programação 
tem sua característica para a implementação de 
leitura e escrita de xmL , algumas mais trabalhosas 
do que outras. É necessário um certo nível de 


conhecimento para fazer a implementação. 


Não criaremos uma API complexa para demonstrar o 
funcionamento do SOAP com o Zend Expressive, mas sim 
uma API bem simples em que passaremos um XML 
contendo os dados de acesso de um usuário, e obteremos 
uma resposta de sucesso ou falha. 


3.3 REST (Representational State Transfer) 


REST (Representational State Transfer), ou Transferência 
de Estado Representacional em português, é uma 
arquitetura baseada no protocolo de comunicação HTTP. 
Através dessa arquitetura é possível fazer com que as 
aplicações se comuniquem independentemente do tipo de 
plataforma que está sendo utilizada. 


A diferença entre REST e SOAP é simples: SOAP aceita 
apenas requisições no formato XML, já o REST, por ser 
totalmente baseado no HTTP, aceita vários tipos de 
requisições como: XML, JSON, binário e entre outros. 
Nesse aspecto, o REST é bastante flexível em 
comparação ao SOAP. 


Para entendermos o funcionamento de uma API REST 
imagine o seguinte cenário: você acessa sua conta do 
banco através do seu computador para verificar o seu 
saldo, porém em um determinado momento você não está 
diante do seu computador, mas está com seu smartphone 
em mãos e decide consultar novamente seu saldo no 
banco. Até aí tudo bem, você informa sua agência, conta 
e sua senha no app e você obtém o saldo da sua conta. 


A pergunta que faço é: o banco desenvolveu um mesmo 
serviço para cada tipo de plataforma existente, ou seja, 
um código para Windows, outro para Linux, outro para 
MAC, outro para Android? Não. 


O banco simplesmente desenvolveu uma API que fornece 
vários serviços para que aplicações desenvolvidas em 
diversas plataformas possam fazer a comunicação e obter 
a informação desejada. 


Para facilitar o entendimento de como funciona uma 
aplicação baseada em arquitetura REST, veja a imagem a 
seguir: 





i, Ne APLICACOES 
APPLE by EXA WEB 





APLICACOES APLICACOES 
ANDROID WINDOWS 


Figura 3.2: Funcionamento de Aplicações REST 


Como podemos ver na imagem anterior, a API 
disponibiliza os serviços necessários para que todas as 


demais aplicações possam fazer a utilização, 
independentemente da plataforma que está solicitando a 
requisição, ou seja, não é necessário escrever um código 
específico para cada plataforma, basta desenvolver uma 
API que disponibilizará todos os serviços necessários, 
evitando mais trabalho e, consequentemente, mais 
investimentos. 


Para entendermos a estrutura básica de uma aplicação 
REST, vamos ver algumas características peculiares 
dessa arquitetura, como: 


e Client-Server - separação das responsabilidades 
entre cliente e servidor; o cliente não se preocupa 
com a lógica da API em si, apenas efetua as 
requisições. 


e Stateless - um mesmo cliente pode fazer inúmeras 
requisições, mas o tratamento de cada requisição 
deve ser feito de forma independente, ou seja, cada 
requisição é tratada separadamente de acordo com 
as informações contidas nela. 


e Cacheable - as respostas devem ser cacheadas 
para que não ocorram processamentos 
desnecessários, assim, quando houver outra 
requisição para obter o mesmo dado, ele já estará 
em cache e a resposta será mais rápida, já que não 
será necessário consultar novamente o banco de 
dados. 


e Uniform Interface - a API deve ser baseada em 
interface ou contratos, como muitos preferem 
chamar, assim sua manutenibilidade se torna mais 


fácil. Basicamente, quanto mais genérica for a API, 
melhor será. 


e Layered System - a aplicação deve ser baseada em 
camadas, fazendo com que a aplicação apenas se 
preocupe com a comunicação. E essa comunicação 
não deve ser feita diretamente com o servidor, mas 
sim com uma outra camada responsável pela 
comunicação com a aplicação. Geralmente, pode 
ser uma camada de [load balancer que se 
responsabiliza pelo balanceamento de carga. 


e Code On Demand (é opcional) - é opcional e não faz 
parte da arquitetura propriamente dita, mas permite 
que o cliente execute código sob demanda. 


A simplicidade e a clareza da arquitetura REST fez com 
que muitas empresas rapidamente começassem a 
desenvolver novos modelos de APIs, mas por quê? Quais 
as vantagens e desvantagens dessa arquitetura”? 


Vantagens 


e Alto nível de interoperabilidade - possui um alto 
nível de interoperabilidade com outros tipos de 
sistemas pois a comunicação funciona de forma 
semelhante ao SOAP, porém é baseado totalmente 
no HTTP. 


e Possui alta performance - é extremamente rápido, 
há quem diga que é mais rápido do que SOAP que 
possui um overhead a mais. Ambos sao 
extremamente rápidos, depende muito do tipo de 
linguagem de programação que está sendo utilizada 


na construção da API e nos conceitos aplicados, 
mas em REST, por não se tratar de um envio de 
XML, as requisições costumam ser mais rápidas. 


e Flexibilidade - o desenvolvedor não fica amarrado 
apenas um tipo de requisição, como é o caso do 
SOAP, em que as requisições são feitas em XML. 
As requisições em REST podem ser feitas de outras 
maneiras; o padrão é o JSON, mas pode-se ter 
binário, XML entre outros. REST permite que você 
desenvolva da maneira que desejar, por isso é 
altamente flexível. 


Desvantagens 


e É necessário um conhecimento básico - para 
fazer a leitura dos dados, já que os dados não estão 
dentro de uma TAG como no SOAP. A maioria das 
APIs REST devolve a resposta em formato JSON 


e Perda da interoperabilidade - por ser flexível, 
deve-se tomar cuidado para não perder a 
interoperabilidade pois tudo tem que ser pensado 
corretamente para que os devidos erros possam ser 
capturados e tratados adequadamente para que as 
aplicações clientes não obtenham erros que não 
foram tratados pela API. 


Assim como o SOAP, o REST é uma arquitetura muito 
poderosa que se bem implementada poderá alcançar 
resultados incríveis e plenamente satisfatórios. Mais 
adiante teremos um capítulo em que faremos uma API 
simples de CRUD de usuários para que você possa fixar o 
conhecimento da melhor maneira possível. 


RESTful 


RESTful nada mais é do que a implementação da 
arquitetura REST, ou seja, é colocar em prática os 
embasamentos e características do REST na API que 
está sendo desenvolvida. 


Não basta apenas desenvolver os serviços em GET , 
POST, PUT, PATCH, DELETE € achar que você já possui 
uma API RESTful, pois para isso é necessário seguir os 
conceitos da arquitetura REST de forma coesa. Também 
há níveis em que os conceitos do REST mencionados 
anteriormente devem ser aplicados, chamados de 
Richardson Maturity Model. Para que você possa 
conhecer melhor sobre esses níveis, acesse o link: 
https://martinfowler.com/articles/richardsonMaturityModel. 
html/. Nele, tem uma descrição bem detalhada de cada 
nível, mas vamos ver uma breve explicação: 


e Nivel 0 - ausência de regras; 

e Nível 1 - deve possuir resources (recursos); 

e Nível 2 - utilização dos verbos HTTP, para uma 
mesma URI pode-se ter verbos diferentes, por 
exemplo: cet /usuários, post /usuários; 

e Nível 3 - fornecimento de informações necessárias 
para o cliente para que a comunicação seja feita 
entre cliente-servidor, HATEOAS (Hypertext As The 
Engine Of Application State). 


se a API atender todos esses conceitos do Richardson 
Maturity Model e todas as características do REST 
mencionadas anteriormente, então ela é uma API 
RESTful. Não faremos um projeto mostrando como 
construir uma API RESTful, mas saiba da existência 


desse conceito, pois é muito utilizado nos dias de hoje. 
Conclusão 


Abordamos neste capítulo alguns conceitos e arquiteturas 
como: SOAP, REST, RESTful e API que são os principais 
assuntos para a construção de uma API. Conforme vimos, 
uma API fornece uma variedade de serviços para que 
aplicações cliente possam fazer a comunicação e obter as 
informações solicitadas. Mais adiante veremos mais 
detalhes durante a construção da nossa API. No próximo 
capítulo vamos iniciar a preparação do nosso ambiente de 
desenvolvimento. 


CAPÍTULO 4 
Preparando o ambiente 


Antes de iniciarmos nosso projeto, precisamos preparar o 
nosso ambiente. Aqui sera demonstrado o passo a passo 
no Linux e no Windows, mas caso você utilize MAC, a 
instalação é bem semelhante a do Linux. Se preferir, pode 
conferir um passo a passo da instalação completa em 
MAC no link: 
https://www.google.com.br/amp/s/coolestguidesontheplan 
et.com/install-apache-mysql-php-and-phpmyadmin-on- 
macos-high-sierra-10-13/amp/. 


4.1 Linux 


Se você utiliza o Linux baseado em uma distribuição 
Debian (como Ubuntu 14.04, 16.04, 17.04 ou 17.10, Mint, 
Kubuntu etc.) basta seguir os passos descritos a seguir: 


Instalando Apache2 


O QUE É APACHE2? 


Nada mais é do que um servidor Web gratuito e de 
código livre. 





Neste livro vamos utilizar o Apache2 porque é um dos 
servidores mais utilizados no mundo, além de ser fácil de 
configurar. 


Para instalar o Apache2 execute os comandos a seguir: 


sudo apt-get update 
sudo apt-get install apache2 


Será exibida uma lista dos pacotes que serão instalados. 
Pressione y e ENTER para confirmar a instalação. Após o 
término, se tudo ocorreu bem, você deve digitar em seu 
navegador: http://localhost e a página a seguir deverá 
ser exibida: 


l hepufocalhost > 


Ubuntu Logo 


Apache2 Ubuntu Default Page 





This is the default welcome page used to test the correct operation of the Apache? server after 
installation on Ubuntu systems. It is based on the equivalent page on Debian, from which the Ubuntu 
Apache packaging is derived. If you can read this page, it means that the Apache HTTP server 
installed at this site is working properly. You should replace this file (located at /var /waw 
/html/index.html) before continuing to operate your HTTP server. 


If you are a normal user of this web site and don't know what this page is about, this probably means 
that the site is currently unavailable due to maintenance. If the problem persists, please contact the 
site's administrator. 


Ubuntu's Apache? default configuration ts different from the upstream default configuration, and split 
into several files optimized for interaction with Ubuntu tools, The configuration system is fully 
documented in /usr/share/doc/apache2/README.Debian.gz. Refer to this for the full 
documentation. Documentation for the web server itself can be found by accessing the manual if the 
apache2-doc package was installed on this server. 
The configuration layout for an Apache2 web server installation on Ubuntu systems is as follows: 
| /etc/apache2/ 
| |-- apache2.conf 
| | `=- ports.conf 
| |+- mods-enabled 
| |-- *. load 
|| =- *.conf 
| |-- conf-enabled 
i | “-- *.conf 
|-- sites-enabled 
| - *.conf 


Figura 4.1: Página inicial do Apache2 


Com o êxito da instalação do Apache2 podemos seguir 


para o próximo passo. 


Instalando o MySQL 


O que é MySQL? 


E um banco de dados relacional responsável por 
realizar o armazenamento de informações. 





Vamos utilizar o MySQL porque é fácil e não requer 
muitas configurações e um conhecimento mais 
aprofundado, e até mesmo quem está começando a 
trabalhar com banco de dados pode aprendê-lo facilmente 
em algumas poucas horas. O MySQL atende 
perfeitamente o que vamos desenvolver no decorrer deste 
livro. 


Para instalar o MySQL basta executar o comando a 
seguir: 


sudo apt-get install mysql-server 


Novamente, será exibida uma lista dos pacotes que serão 
instalados, e para confirmar a instalação tecle Y e ENTER. 
Durante o processo, será solicitado que você informe uma 
senha para o banco de dados que será utilizada para 
fazer o acesso local para seu devido gerenciamento, 
conforme mostra a imagem a seguir: 


Configuring mysql-server-5.7 
While not mandatory, it is highly recommended that you set a password 
for the MySOL administrative “root” user. 


If this field is left blank, the password will not be changed. 


New password for the MySQL "root" user: 





Figura 4.2: Informando a senha do usuario no MySQL 


Apos informar a senha, sera solicitado que vocé a redigite. 
Com isso, a instalação do MySQL prosseguirá 
normalmente. Quando a instalação estiver finalizada, 
poderemos seguir para o próximo passo. 


Instalando o PHP 


Para fazer a instalação do PHP, primeiramente vamos 
adicionar o repositório do PHP para que o Linux o 
reconheça e possa fazer sua instalação. Para isso, 
execute o comando a seguir: 


sudo add-apt-repository ppa:ondrej/php 


Após ter adicionado o repositório do PHP, execute o 
comando a seguir para atualizar as dependências de seu 
Linux: 


sudo apt-get update 


MAS O QUE SÃO ESSAS DEPENDÊNCIAS? 


São pacotes/bibliotecas que são requeridos para a 
instalação de um outro pacote/biblioteca. 





Sempre que adicionarmos um novo repositório no Linux, 
devemos fazer a atualização das dependências para que 
o repositório que foi adicionado tenha os 
pacotes/bibliotecas disponíveis para instalação. 


Depois que as dependências do seu Linux estiverem 
atualizadas, podemos instalar o nosso PHP e algumas 
bibliotecas que serão necessárias para o nosso projeto: 


sudo apt-get install php7.2 php7.2-mysql php7.2-json 
php7.2-curl php7.2-xml 


O que sao bibliotecas? 


São pacotes que contêm códigos específicos que 


atendem uma determinada tarefa para a resolução de 
um problema. 





A seguir, você pode conferir uma lista das 
bibliotecas/pacotes que vamos instalar em nosso 
ambiente: 


e php7.2 - contém o PHP propriamente dito. 

e php7.2-mysql - responsável por realizar a 
comunicacáo do PHP com o MySQL, esse é o driver 
do MySQL para o PHP. 


O si 


php7.2-json - pacote responsável por fornecer o 
módulo JSON para o PHP para que seja possível 
trabalhar com o formato JSON. 

php7.2-curl - responsável por efetuar as 
requisições. Como vamos trabalhar com API, 
devemos ter esse módulo instalado para que essas 
requisições possam ser efetuadas pelo PHP. 

php7.2-xml - esse pacote é responsável por 
disponibilizar a manipulação de arquivos XML 
através de classes e funções específicas. 


stema informará que serão instaladas várias 


dependências referentes aos pacotes do PHP que 
desejamos instalar. Tecle y e ENTER para confirmar a 
instalação. Se não ocorreram erros durante a instalação, o 
seu PHP está instalado e pronto para ser utilizado. Caso 


tenha 
descr 


Para 


ocorrido algum erro, por favor reveja os passos 
itos e tente novamente. 


verificar se o PHP está corretamente configurado 


vamos criar um pequeno script que trará as informações 


do P 


HP que acabamos de instalar. Crie um arquivo 


chamado info.php dentro do diretório /var/www/html/ 
com o seguinte conteudo: 


<?php 
phpinfo(); 
Salve o arquivo e em seu navegador digite: 


http://localhost/info.php/. Se tudo ocorreu bem, você verá 
uma página semelhante à apresentada a seguir: 





System | Linux jnones 4.10.0-38-generk #42~16.04.1-Ubuntu SMP Tue Oct 10 16:32:20 UTC 2017 x6_64 | 
Build Date ¡May 5 2018 04:55:21 


Server API | Apache 2.0 Handler 
Virtual Directory Support | Guabled 

A a A . v ~ 
Configuration File (php.ini) Path | Meciphpy7 Lapacho? 


Loaded Configuration File  Metciphpy? Llepache2/php, ini 














seta, jetcip J 
Mtciphpy? Lapache2 conf d/20-gettest. ini, feteiphp/? ' 
7 Lfapache2/conf.d/200n.ini, jetciphp/7. e2/comt d/20-phar.in fphps7. I fapache2 
conf. d/20-posix isi, Mtcphp/T, Lapache2/contd20-readine ini, etc/pnp/] Lrapache2icant d/20- 
_ shmop. ini, fetc/php/?.1/apache2/cant d/20-sockets mi, jetc/php/7.1/apache2/cont d/20 sq. ini, 
à detciphpy7, lapache2/cont d/20-sysvsem ini etc (pips? apache? ont. d/20-sysvshen, im. eaciphp 
| (7 AMpache2/cont.d/204okenizer.ini 
PHP API | 20160303 
PHP Extension 20160303 
Zend Extension | 320160303 
Zend Extension Build | API320160303.NTS 
PHP Extension Build | MAZOLEOIOI.NTS 
te oe = 
Debug Build “oa 
Zend Signal Handling “enabled 
Zend Memory Manager enabled 
Zend Multibyte Support  Esabied 
IPv6 Support enabled 
DTrace Support _avadable, dsabled i 
Registered PHP Streams | https. ftps, compress.zii, php, Mile, glob, data, http, ftp, phar 
Registered Stream Socket Transports itep. udp. unie, udg. ssl Us, tisvl 0, tisvi. t. tisvi,2 
Registered Stream Filters EA os 13, strmg.toupper, string tolower, string.stnp tags. convert.*, consumed. dechunk, 
convert, iconu" 


Figura 4.3: Informações do PHP 


Com isso, já teremos instalado o essencial para 
trabalharmos com o PHP. 


4.2 Windows 


Se você é usuário do Windows, nós vamos utilizar o 
Wamp Server, que já vem com o Apache + MySQL + 
PHP. O processo de instalação é bem simples, basta 
fazer o download no site oficial do fabricante: 
http://www .wampserver.com/en/. Após o download ter sido 
concluído com sucesso, abra o arquivo baixado e avance 


até o final. Basta aguardar o término da instalação, que o 
Apache + MySQL + PHP já estarão instalados e prontos 
para uso em sua máquina. Depois que a instalação do 
Wamp estiver concluida, em seu navegador, você poderá 
digitar http://localhost na barra de endereço. Se tudo 
ocorreu bem, a página inicial do Wamp deverá ser exibida 
conforme mostra a imagem a seguir: 





W 
ese LS Jam engs [cesar - 
Server Configuration 
Apache Versia: 7437 - Docsmentation 
PHP Version: 7.24 Documentation 
Server Software: ¿5000 7.437 AnI] PHP 7.2.4 - Port exfined for Apache: RO 
Laadad Extendinas: asparelharde De doneth $ tr $ calendar 
A com comer De core ac De ari 
A dure De com $ ex * mento 
Arr de cá de gonest de gmp 
A nos $ cow de mep De mti 
A jor » veo de tb e mang 
& mrg B wysgnd de coens poe 
Arno De pda _mpil de pio sbt D my 
& cade De Select É ses De Simplexda 
Å wx De sockets de st De pta 
& zard De tina BR wt dh debug 
en! À- rosd É writs; D umbmertor 
aa É Jed ORacio $ zo De zib 
MySQl Version: 3.721 Port defned for MySQL: 1306 — Documentation 
MarisDS Version: 102.14 - Part defisead for ManaD8: 3307 - Documentation 
Tools Your Projects Your Aliases Your VirtualHost 
phpiedo() No props pet. y adn ar sy localhost 
phpempadrmén To creste a nem one, jux cos o o phpmyadmin 
Add a Virtual Host Grectery in www, a papsysinto 


Wamprerver Porm 


Figura 4.4: Pagina inicial do Wamp 


Caso a versao do PHP nao esteja na versao 7.2, vocé 
pode altera-la sem nenhum problema. Para isso, clique no 
icone do Wamp em sua barra de tarefas, em seguida, 
acesse o menu PHP > version (versão) e selecione a 
versão 7.2, conforme mostra a imagem a seguir: 


"sd Made in France by Otomatic _ 
Oh Localhost 

ES phpMyAdmin 4.7.9 
ES Adminer 4.6.2 
E Your VirtualHosts + 




















i A www directory 
$ | MA MS ES: Apache 
Ba Version 3 wv 5.6.35 
Ka) PHP settings PO 7029 


it) PHP extensions k 7.1,16 
E php.ini 
Po PHP error log 


næ s =o 


des PHP documentation 










iL 5.7.21 + 
E B 10.2.14 P| 
3- 32bit- Services 
re Services 








Stop All Services 
Restart All Services 












































Figura 4.5: Alterando a versão do PHP 


Feito isso, automaticamente o Wamp reiniciará todos os 
serviços para que a alteração tenha efeito. Para verificar 
se o PHP está corretamente configurado, na página inicial 
do Wamp, no canto inferior esquerdo em Tools existe 
uma opção chamada phpinfo() . Basta clicar nela, que 
uma página semelhante à mostrada a seguir deverá ser 
exibida, contendo as informações do PHP: 


E 
reat 
| Dl] 1D 
e. A 





| System Windows NT DESKTOP-7QU2LTL 10.0 subs 16208 (Windows 10) 1565 

| Beit Date Mae 28 2018 042332 

| Compler MSVC15 (Visual C++ 2017) 

Architecture 26 

“Confare Commang compt mologo configure js "enable snapshot ould "enable cebu pack “wih pdo-co=c’php saap 
bulld.deps_auxorado'eBiinstantchent_12_1\sck shared "-wth-00iB-12c=C'ghp-snap-bulddeçs mudoracie 

| uBBinstartcient 12 1isdeshares "-enable-otject-cut-dr= /oby” "--enadle-comdotet=shared’ “mou 

| analar "Ahipa" 

| Server A Apache 20 Handler 

| Virtual Directory Support ecabias 7 

“Configuration Fte (php nú Path Cwancows 

Loaded Configeration fie C weerotimapachelapacha2 4 htmohp ini 

, Scan mis dir for additional ini files (nona) 

_ Additional jni files parsed inona) 

| PHP API 20170718 

| PHP Extension 20170718 

| Lend Extension 320170738 y o 

Lend Extension Buig MPRISONTOTIS TS VCIS 

PHP Extension Eita APROTTO7 MA TE VCIS 

Debug Paik no 

| Thread Safety enana 

“Zend Signal Handing Ms ated 

Lord Multibyte Support pronded dy mostring 

IPV Support enabled 

_ Ofrace Sapport dsatied 

| Registered PHP Streams pre, fre, Glo, Gata, hip, Ne, Lip, comeress 266, Compress taira. Nites, lps, phar 

| Registered Samam Socket Transports kca wap, ash tis, 1501 0 15011, tewi? 

| Registered Stream Finers em string cott3 string toupper, sting tolower string strip tags convert * consumed dechunk ab". 

The program mañas uae CAT Zend DO LEE VE 

 Temsengnesau Co T E eae ada zendengine 

"WMA Zend OP cache v7 2 4, Capmgth ic) 1099-2018, By Zand Technologas 


, Wat X000u9 12 6 0, Copragia (c) 2002-2018, dy Derick Rahana 


Figura 4.6: Informações do PHP no Wamp 


4.3 Instalações e configurações adicionais 


O nosso ambiente está pronto para ser utilizado de 
maneira básica, sem frameworks ou URL amigáveis. Mas 
como vamos trabalhar com o Zend Expressive, 
precisamos realizar algumas instalações e configurações 
adicionais. 


Habilitando ModRewrite ou RewriteModule no Linux 


O ModRewrite OU RewriteModule é um modulo do servidor 
Apache que é necessário para trabalhar com reescrita de 
URL, as famosas URL amigáveis. 


Para habilitar o módulo em sistemas Linux, basta executar 
os comandos a seguir: 


sudo a2enmod rewrite 
sudo service apache2 restart 


E pronto! O primeiro comando habilita o modulo no 
servidor Apache, e o segundo reinicia o servidor para que 
a configuração tenha efeito. 


Habilitando  ModRewrite ou  RewriteModule no 
Windows 


Para você que utiliza o Windows, habilitar o modRewrite 
no Wamp também é bastante simples e não precisa 
digitar nada. Clique no icone do Wamp em sua barra de 
tarefas, vá até a opção apache > Apache modules e, por 
fim, selecione a opção rewrite module (caso não esteja 
com o ícone verde ao lado) conforme mostra a imagem a 
seguir: 


proxy module 
proxy scg module 
proxy uwsgl module 
proxy wstunnel module 
ratelimit module 
reflector module 


remoteip module 







regtimecut module 








E request module 
| Version 


| w Service administration 'wampapache' 
EE) Apache modules 
FẸ Alias directories k 
| E: httpd.conf 

| Po httpd-vhosts.conf 





rewrte module 


sed module 

session cookie module 
session crypto module 
session dbd module 

| 2 PE | session module 

£. Apache error log | 

| E. Apache access log pe wineries 
| lig Apache documentation 


slotmem_plain_module 


slotmem_shm_module 





encarhe dhrm module 
F 





Figura 4.7: Habilitando Rewrite Module no Wamp 


Após esse passo, o Wamp deverá ser reinicializado 
automaticamente para que as alterações tenham efeito. 
Se tudo ocorreu bem, o ícone do Wamp deverá ficar verde 
novamente indicando que o serviço está funcionando 
normalmente. 


Instalando SGDB (Sistema de Gerenciamento de 
Banco de Dados) no Linux 


O que É SGDB (SISTEMA DE GERENCIAMENTO DE BANCO DE 
DADOS) 


Como o próprio nome sugere, é um sistema de 


gerenciamento de banco de dados ou uma 
aplicação/software que é responsável por facilitar o 
gerenciamento de um banco de dados, seja para 
executar consultas, criar tabelas, inserir dados etc. 





Vamos utilizar um SGDB para facilitar o gerenciamento do 
nosso banco de dados, pois por linha de comando seria 
mais complexo e demandaria mais tempo. 


Se você utiliza o Linux então será necessário fazer a 
instalação de um SGDB. Neste livro, vamos utilizar o 
MySQL Workbench. Para fazer a instalação, basta 
executar os comandos a seguir: 


sudo apt-get update 
sudo apt-get install mysql-workbench 


Após o término da instalação, basta executar o comando 
a seguir para executar o programa: 


mysql-workbench 


Se a execução do programa foi bem-sucedida, a janela do 
programa deverá ser exibida com sucesso. 


Instalando SGDB no Windows 


se você utiliza o Windows, com a instalação do Wamp 
Server, você já terá instalado o PHPMyAdmin e para usá- 


lo basta abrir o seu navegador e digitar 
http://llocalhost/phpmyadmin/ e a página exibida deverá 
ser semelhante à imagem mostrada a seguir: 


phpMyAdmin 
Bemvindo ao phpMyAdmin 


— Lingua - Language 


Portugués - Portuguese zj 


— Entrada e i 


Utilizador : 
Í root | 


Palavra-passe: Po 


Server Choice: — 
MySQL ~] 


Executar 


Figura 4.8: Página de login do PHPMyAdmin 


Note que o campo utilizado mostrado na imagem possui 


como nome root , que é o usuário padrão para o 
gerenciamento do banco de dados. Ao clicar no botão 
Executar , VOCÉ será redirecionado para a página inicial 
para fazer o gerenciamento de seus bancos de dados, 
conforme mostra a imagem a seguir: 








add Sh. bh MA = a 

mi DIM n Bie r Bt staal + - — ia - ~~ = — — = os E - a - — 

Dri ' sr A e E A A a DEE a e a A en A amam A Da Da | 
sor tw at J J D ` ce etas Ce emas porta To ria riras Hort koe V Ma 


er pee 





We era terein 4 e asda MSR OTe TRF: 
- 2. a Ipe deversde Vy til 
nuca co ğ spee g ° > Vet: do terete STO) VU, SCI Cerensd, Soret 
GAL 








Figura 4.9: Pagina de login do PHPMyAdmin 


Caso você nao goste de utilizar o PHPMyAdmin ou prefira 
instalar o MySQL Workbench, vocé pode fazer isso 
acessando O link 
https://dev.mysql.com/downloads/workbench/. A 
instalação é bem simples como qualquer outra instalação 
no Windows. 


Instalando o Composer no Linux 


O Composer nada mais é que um gerenciador de pacotes 
para PHP. Com ele, podemos baixar diversas 
dependências para serem utilizadas em nossos projetos. 
Para saber mais sobre esse gerenciador de pacotes 


acesse: https://getcomposer.org/. 


Para instalar o Composer, execute o comando a seguir: 


sudo php -r "copy('https://getcomposer.org/installer', 
'/tmp/composer-setup.php');" 


O comando anterior baixará o instalador do Composer no 
diretório /tmp . O próximo passo é verificarmos se a 
assinatura pública do arquivo baixado corresponde a 
assinatura pública no site do Composer. Para isso, 
execute o comando: 


sudo php -r "if (hash file('SHA384'!, '/tmp/composer - 
setup.php') === 
'544e09ee996cdf60ece3804abc52599c22b1f40f4323403c44d44fdf 
dd586475ca9813a858088ffbc1f233e9b180f061') { echo 
‘Installer verified'; } else { echo ‘Installer corrupt'; 
unlink('/tmp/composer-setup.php'); } echo PHP_EOL; 


Um ponto importante a ser levado em consideração é 
quanto ao hash que está presente no comando anterior. 
Ele é obtido no site oficial do Composer 
https://getcomposer.org/download/. Você pode 
simplesmente copiar e colar o comando que está presente 
no site, que funcionará sem problemas. 


Se tudo ocorreu bem você deverá receber a mensagem 
Installer Verified e já podemos seguir em frente. 


O próximo passo é instalar o Composer para uso global, 
ou seja, sem a necessidade de repetir os passos para 
cada projeto novo. Para fazer isso, execute o comando a 
seguir: 


sudo php /tmp/composer-setup.php --install- 


dir=/usr/local/bin --filename=composer 


Você deverá receber uma saída semelhante à mostrada 
na imagem a seguir: 


sudo php /tmp/composer-setup.php --install-dir=/usr/local/bir 
--filename=composer 
sudo: unable to resolve host jhones: Connection timed out 
[sudo] password for jhones: 





Figura 4.10: Instalação do Composer para uso global 


Para verificar se o Composer esta instalado corretamente, 
basta executar o comando: 


composer --version 


Até o momento da escrita deste livro o Composer está na 
versão 1.6.5. Após executar o comando anterior, o 
Composer deverá retornar uma mensagem informando a 
versão instalada em sua máquina conforme mostra a 
seguir: 


composer --version 
version 2018-05-04 11:44:59 





Figura 4.11: Conferindo a versão do Composer 


Com isso, 0 Composer esta instalado corretamente e 
pronto para uso em sua máquina. 


Instalando o Composer no Windows 


Para realizar a instalação, acesse o site 
https://getcomposer.org/doc/00-intro.md#installation- 

windows/ e baixe o arquivo do Composer mais recente. 
Feito o download, basta clicar duas vezes em cima do 
arquivo baixado e seguir o processo de instalação como 
qualquer outro programa. Após a conclusão, abra o CMD 
ou o Windows Power Shell e execute o comando a seguir: 


composer --version 


Se o resultado exibido na tela for semelhante ao mostrado 
a seguir, a instalação do Composer foi realizada com 
sucesso: 





EX Windows PowerShell 


PS C:\Users\Jhones> composer --version 
-65-64 11:44:59 





Figura 4.12: Conferindo a versáo do Composer no Windows 
Conclusáo 


Com isso, finalizamos a preparacáo do nosso ambiente de 
aprendizagem que será utilizado neste livro e podemos 
seguir para o próximo capítulo. 


CAPÍTULO 5 
Clonagem e configuracáo do Zend 
Expressive 


Finalmente vamos comecar nossa jornada rumo ao 
conhecimento do Zend Expressive e suas 
funcionalidades. Uma das principais funcionalidades do 
Zend Expressive é trabalhar com middlewares que 
facilitam o desenvolvimento da aplicação. Podemos ter 
diversos middlewares em nossa aplicação. 


A maior utilização do Zend Expressive é para o 
desenvolvimento de APIs e aplicações minimalistas. 
Neste livro, vamos desenvolver uma API de comunicação 
entre usuários, em que um usuário enviará uma 
mensagem e um outro usuário vai responder a essa 
mensagem, bem semelhante a uma aplicação de 
chamadas. 


Agora, vamos seguir com a instalação do Zend 
Expressive. O primeiro passo é clonar o projeto em nosso 
ambiente de desenvolvimento. Acesse o site 
https://docs.zendframework.com/zend-expressive/ para 
fazer o clone do Zend Expressive. 


Vamos clonar o projeto que já contém o esqueleto básico 
para trabalhar, para isso execute o comando a seguir em 
seu terminal: 


composer create-project zendframework/zend-expressive- 
skeleton /var/www/livro-zend-expressive 


Veja que o nome do projeto que estou criando é livro- 
zend-expressive , mas você pode colocar um nome de sua 
escolha. O nosso projeto será criado dentro do diretório 
/var/www , que é o diretório utilizado pelo Apache. Quando 
O processo de criação for iniciado, o Zend Expressive fara 
uma série de perguntas sobre o que você deseja instalar. 


A primeira pergunta é sobre o tipo de instalação que 
desejamos. A imagem a seguir mostra essa etapa: 





Figura 5.1: Selecione o tipo de instalação desejável 


Como você pode ver, o Zend Expressive nos fornece três 
opções: 


1. Instalação mínima, que só terá a configuração e 
nada mais, ou seja, não conterá middleware, 
templates ou assets. 

2. Instalação que contém a estrutura do codigo, essa é 
a opção padrão definida pelo Zend Expressive. 

3. Instalação modular, que contém a estrutura modular 
do código, essa é a opção recomendada. 


Vamos selecionar a opção 3 porque ela já fornecerá uma 
estrutura modular, isso significa que podemos ter diversos 
módulos dentro da nossa API. Por exemplo, por padrão, o 
módulo padrão é o App , mas podemos ter também outros 


módulos como: Livro, Jhones etc., então tecle ENTER 
para prosseguir com a instalação. 


A próxima pergunta é sobre qual contêiner de injeção de 
dependência desejamos instalar. 
O QUE É CONTEINER DE INJEÇÃO DE DEPENDÊNCIA ? 


Um contêiner de injeção de dependências realiza o 
controle das instâncias das classes, informando 
exatamente quando um objeto deverá ser criado. 


vicemanager 


Symfony DI Container 
your selection or type a composer package name and version 





Figura 5.2: Selecione o tipo de contêiner de injeção de dependência 


Será exibida uma lista de opções de contêineres de 
injeção de dependência, com as seguintes opções: 


1. Aura.bi - UM contêiner de injeção de dependência 
serializável com injeção de construtor e setter, 
reconhecimento de interface, herança de 
configuração e muito mais. 

2. Pimple - um pequeno contêiner de injeção de 
dependência para PHP baseado no Symfony. 

3. zend-servicemanager - baseado no Zend Framework, 
o padrão de design do Service Locator é 
implementado pelo componente 

Zend\ServiceManager . O Service Locator é um 
localizador de serviços/objetos, encarregado de 


recuperar outros objetos. 

4. Auryn - é um injetor de dependência recursivo. 

O. Symfony DI Container - permite padronizar e 
centralizar a maneira como os objetos são 
construídos em sua aplicação. 


Todas as opções listadas anteriormente são contêineres 
de injeção de dependência. Selecione a opção 3 - zend- 
servicemanager , pois é bem simples de trabalhar. Em 
seguida, tecle ENTER para prosseguir com a instalação. 


A próxima pergunta que o Zend Expressive fará é sobre 
qual sistema de rotas desejamos instalar, conforme 
mostra a imagem a seguir: 


[1] Aura.Router 
[2] FastRoute 


[3] zend-router 
Make your selection or type a composer package name and version 





Figura 5.3: Selecionando o tipo de sistema de rotas 


O QUE É SISTEMA DE ROTAS? 


Nada mais é que o modo como as rotas são definidas 


e utilizadas dentro da sua aplicação. É através das 
rotas definidas que conseguiremos utilizar 
determinados recursos da nossa API. 





Será exibida uma lista de opções de sistemas de rotas 
com as seguintes opções: 


1. Aura.Router - roteamento Web poderoso e flexível 
para requisições da PSR-7. 


2. FastRoute - esta biblioteca fornece uma 
implementação rápida baseada em expressões 
regulares. 

3. zend-router - O roteamento funciona de acordo com 
as solicitações e respostas do zend-http . 


Temos três opções de sistema de rotas para 
selecionarmos. Vamos selecionar a opção 1, 
Aura.Router . Tecle ENTER para prosseguir com a 
instalação. Estamos escolhendo essa opção porque o 
aura.Router é bem simples, fácil, prático e flexível, além 
de trabalhar com as requisições baseadas na PSR-7. 


A próxima pergunta é sobre o tipo de template de 
visualização que desejamos ou não instalar conforme 
mostra a imagem a seguir: 


Plates 
Twig 


None of the above 


| 

] 

] zend-view 

| 

ake your selection or type a composer package name and version 





Figura 5.4: Selecionando o tipo de template de visualização 


O QUE É TEMPLATE DE VISUALIZAÇÃO? 


É o modo como as informações serão apresentadas 


para os usuários, são as Views ou páginas de 
exibição, como muitos preferem chamar. 





Será exibida uma lista de opções, são elas: 


1. Plates - é um sistema de template PHP nativo que 


é rápido, fácil de usar e de estender. 

2. Twig - é uma linguagem modelo para PHP que 
utiliza uma sintaxe semelhante às linguagens de 
modelos Django e Jinja que inspiraram o Twig. 

3. zend-view installs zend-servicemanager - fornece a 
camada view do sistema Zend Framework MVC. E 
um sistema de múltiplas camadas que permite uma 
variedade de mecanismos para extensão, 
substituição e muito mais. n. None of the above - 
nenhuma das opções, caso não deseje instalar 
nenhum deles. 


Vamos selecionar a opção 3, zend-view . Aqui estamos 
selecionando essa opção porque o código fica mais 
legível e, além disso, é bem simples. Tecle ENTER para 
prosseguir com a instalação. 


A próxima e última pergunta que o Zend Expressive fará é 
sobre qual o tipo de manipulador de erros desejamos 
utilizar. 


O QUE É MANIPULADOR DE ERROS OU ERROR HANDLER? 


É o modo como os erros da aplicação serão tratados 
e lançados para o usuário. 





Veja a seguir a imagem contendo as opções disponíveis 
para selecionarmos: 





Figura 5.5: Selecionando o tipo de manipulador de erros 


A imagem anterior disponibiliza para escolha uma lista 
contendo as seguintes opções: 


1. Whoops - é um manipulador de erros para PHP que 
fornece uma interface de erro que ajuda nos ajuda a 
depurar nossos projetos Web. n. None of the above - 
nenhuma das opções, caso você não deseje instalar 
um manipulador de erros. 


Como você pode ver na imagem anterior, há apenas duas 
opções, nós selecionamos a opção 1 que corresponde 
ao whoops . Tecle ENTER para prosseguir com a 
instalação. Estamos selecionando essa opção, porque o 


Whoops é um excelente manipulador de erros que nos 
ajuda a identificar os erros de forma eficaz e bem intuitiva. 


Após essa etapa, o Zend Expressive começará a baixar 
uma série de pacotes. Ao término da instalação, você terá 
uma saída semelhante à mostrada na imagem a seguir: 


iTramework/zend-view suggests installing zendTtramework/ ze 
zendframework/zend-view suggests installing zendframework/ze 
zendframework/zend-view suggests installing zendframework/ze 
zendframework/zend-servicemanager suggests installing ocrami 
zendframework/zend-expressive-template suggests installing z 
zendframework/zend-expressive-template suggests installing z 
zendframework/zend-config-aggregator suggests installing zer 
zendframework/zend-config-aggregator suggests installing zer 
classes) 
zendframework/zend-config-aggregator suggests installing zer 
figuration) 
sebastian/global-state suggests installing ext-uopz (*) 
phpunit/phpunit-mock-objects suggests installing ext-soap (* 
phpunit/phpunit suggests installing phpunit/php-invoker (^2. 
zendframework/zend-expressive suggests installing zendframev 
zendframework/zend-expressive suggests installing zendframer 
zendframework/zend-code suggests installing doctrine/annotat 
symfony/console suggests installing symfony/event-dispatcher 
symfony/console suggests installing symfony/Lock () 
symfony/console suggests installing symfony/process () 
symfony/console suggests installing psr/log-implementation ( 
filp/whoops suggests installing symfony/var-dumper (Pretty E 
filp/whoops suggests installing whoops/soap (Formats errors 


Generating version class... 

.. -done generating version class 
> zf-development-mode enable 
You are now in development mode. 





Figura 5.6: Instalagao concluida do Zend Expressive 


Pronto. O microframework realizou a instalação de alguns 
pacotes que são necessários para o seu funcionamento, é 
o que chamamos de core. Com o Zend Expressive 
instalado em nosso ambiente já podemos verificar se ele 
está funcionando corretamente. É o que veremos na 
próxima seção. 


5.1 Hello Zend Expressive 


Para verificar se o microframework está funcionando 
corretamente, basta executar o comando a seguir em seu 
terminal, na raiz do projeto: 


composer serve 


Esse comando fará com que o servidor embutido dentro 
do PHP seja executado e gere um endereço de para 
acessar o projeto por meio do navegador. O endereço 
gerado você pode conferir na linha: php -S 0.0.0.0:8080 - 
t public/ conforme mostra a imagem a seguir: 


Livro-zend-expressive # composer serve 





> php -5 6.6.68.6:8086 -t public/ 


Figura 5.7: Iniciando o Zend Expressive com Composer Serve 


Perceba que o endereço que o comando gerou foi o 

0.0.0.0:8080 , que você deverá informar em seu 
navegador. Dessa forma, uma página semelhante à 
imagem a seguir deverá ser exibida: 
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Welcome to zend-expressive 
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Figura 5.8: Página inicial do Zend Expressive 


Maravilha! O microframework está executando sem a 
necessidade de criar um VHOST dentro do nosso servidor 
Apache. Na próxima seção vamos criar um VHOST no 
Linux para acessarmos o projeto de forma menos 
trabalhosa. 


O que É Um VHOST ou VirtuaL HOST? 


E um arquivo de configuração que possui códigos 
específicos para o funcionamento de um projeto Web 


de forma mais elegante e funcional. Essa 
configuração permite acessarmos nosso projeto por 
meio de um nome, em vez de um IP, como vimos 
anteriormente. 





5.2 Configurando o Zend Expressive com 
VHOST no Linux 


Vimos que é possível executar o Zend Expressive pelo 
comando composer serve , que inicializará o servidor 
embutido dentro do PHP, até aí nenhum problema. Mas 
imagine você ter que digitar o IP e a porta no navegador 
para ter acesso ao projeto, seria cansativo toda vez ter 
que digitar: 0.0.0.0:8080 , concorda”? 


Então, vamos ver agora como configurar o Zend 
Expressive para executar através de um Virtual Host. 
Esse processo fará com que o microframework seja 
executado como se fosse um site através de um 
endereço. 


Criar um VHOST para o nosso projeto no Linux não é una 
tarefa difícil, mas é trabalhosa. Siga os passos descritos 
adiante, que tudo ocorrerá bem, combinado? 


Primeiramente precisamos entrar no diretório sites- 


available dentro do nosso servidor Apache, com o 
comando: 


cd /etc/apache2/sites-available 


Uma vez dentro do diretório, vamos criar o nosso arquivo 
de configuração através do arquivo já existente, com o 
comando: 


sudo cp 000-default.conf livro-zend-expressive.conf 


Esse comando realiza uma cópia do arquivo  000- 
default.conf Com O Nome livro-zend-expressive.conf 
Vamos agora ver o conteudo desse arquivo para que 
possamos alterá-lo. Estou utilizando o Vim para abrir o 
arquivo, mas você pode usar qualquer outro editor de 
texto de sua preferência. 


Para abrir o arquivo que criamos, execute o comando: 


vim livro-zend-expressive.conf 


Seu arquivo deve se parecer com a imagem a seguir: 


webmasterflocalhost 
¡var /www 


S(APACHE LOG DIR)/ . log 
S(APACHE LOG DIR}/access.log combined 


tualHost> 





“Livro-zend-expressive.conf” 31L, 1327C 


Figura 5.9: Conteúdo padrão do arquivo de configuração 


Nós faremos algumas alterações nesse arquivo para que 
o nosso projeto possa funcionar corretamente. 
Primeiramente, vamos ao código que colocaremos em 
nosso arquivo de configuração: 


<VirtualHost *:80> 
ServerName livro-zend-expressive.dev 
DocumentRoot /var/www/livro-zend-expressive/public 
CustomLog /var/log/apache2/access.log common 
ErrorLog /var/log/apache2/error.log 


<Directory /var/www/livro-zend-expressive/public> 
<IfModule mod_rewrite.c> 
RewriteEngine On 
RewriteCond %{REQUEST_FILENAME} ! -f 
RewriteRule 4 index.php [L] 


</IfModule> 
</Directory> 
</VirtualHost> 


Nesse código, estamos informando que o ServerName é 
livro-zend-expressive.dev , esse nome é o que vamos 
digitar na barra de endereço do navegador. Um outro 
ponto bem importante é o DocumentRoot , que deve conter 
o caminho completo até a pasta public do nosso projeto. 


Perceba também que temos duas configurações de 
LOGs: cCustomLog € ErrorLog , ambas apontam para a 
pasta de LOG do proprio Apache, que contera tanto LOGs 
de tentativa de acesso, quanto LOGs de erro da 
aplicação. 


Substitua o código que está atualmente dentro do arquivo 
/etc/apache2/sites-available/livro-zend-expressive.conf 
pelo codigo anterior. 


Salve o arquivo e, em seguida, vamos habilitar a 
configuração que acabamos de criar. Para isso, execute o 
comando a seguir: 


azensite livro-zend-expressive 


Agora basta recarregarmos o servico do Apache para que 
a nova configuracáo já esteja disponível para uso: 


service apache2 reload 


Se nenhum erro ocorreu até aqui, então parabéns! 
Acabou? Ainda nao, meu caro amigo, falta apenas 
definirmos o host que vamos acessar ao digitarmos na 
barra de navegação do navegador. Sabe aquele nome 
que definimos dentro do nosso arquivo de configuração 


em ServerName ? É exatamente o mesmo nome que 
vamos colocar no nosso arquivo hosts . Então, abra o 
arquivo no seu editor de texto: 


vim /etc/hosts 
Coloque o código a seguir ao final de seu arquivo hosts : 
127.0.0.1 livro-zend-expressive.dev 


Pronto, salve seu arquivo, abra o seu navegador e digite 
http://livro-zend-expressive.dev/. Se tudo ocorreu bem, a 
pagina inicial do Zend Expressive sera exibida para você. 
Caso tenha ocorrido algum erro, revise os passos com 
calma e atenção que tudo vai dar certo. 


5.3 Configurando VHOST no Wamp Server 


Criar um VHOST no Wamp Server hoje é mais simples e 
não requer muito trabalho. Primeiramente, inicie o seu 
Wamp Server caso ainda não esteja em execução, e 
depois que o ícone do Wamp Server estiver verde, abra 
seu navegador e digite http://localhost . A página inicial 
do Wamp Server deve ser exibida conforme mostra a 
imagem a seguir: 


da; 





WempServer die Za 
ses 3L3 lim | enghst: [eass 
Server Configuration 
Apache Version: 2437 - Docosmentaton 
PHP Version: 724 Documentation 
Server Software: “7000 1.417 (Wind?) PHPT IA - Port defined for Apache: BO 
Laatat Extensions: 9 spechethender De comath de ter? dh endor 
A om come $e & ctype * an 
# toro & do 2 cu * morto 
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Add a Virtual Host dredery in ‘weve, y phpsysinto 


Wampserver forums 


Figura 5.10: Página inicial do Wamp 


Na seção Tools OU Ferramentas , localize no canto inferior 
esquerdo o menu Add a Virtual Host . Ao clicar nele, você 
será redirecionado para uma nova tela, onde você 
informará os dados conforme mostra a imagem a seguir: 


(ly) Add a VirtualHost - Back to homepage 
WampServer 
e vean 1.1.3- Ibe arguh 
Apache Vita “Hosts (EN 
Virtuebtiost siesty defied: 
Sevverame | otahi - Dvectovy . iwang wwa 





Stan the crastioa of the Virtuabtost (May take a whale...) 


Figura 5.11: Criando VHOST no Wamp Server 


No primeiro campo, devemos informar o nome do host , 
ou seja, o nome que vamos digitar para acessar a 
aplicação. Vamos utilizar o nome livro-zend- 
expressive.dev . No segundo campo, devemos informar o 
caminho completo até a pasta public do projeto. No caso 
seria algo semelhante a C:/wamp/www/livro-zend- 
expressive/public . O terceiro campo náo é obrigatório, 
mas se desejar preenché-lo, você deverá informar o IP no 
qual o projeto poderá ser acessado ao digitar na barra de 
endereço do navegador. 


Após ter preenchido os campos obrigatórios, clique no 
botão para criar o VHOST. Você deverá visualizar uma 
página semelhante à imagem a seguir: 


Add a VirtualHost - Back to homepage 


o oser 3 L3- ID lengish | 





Figura 5.12: VHOST criado com sucesso no Wamp Server 


O próximo passo é reiniciar o serviço de DNS do Wamp 
Server. No menu Tools , selecione a opção Restart DNS. 


Pronto, basta aguardar o ícone do Wamp Server ficar 
verde novamente. Abra o seu navegador e digite 
http://livro-zend-expressive.dev , se tudo ocorreu bem, a 
pagina inicial do Zend Expressive devera ser exibida. 


Parabens, o Zend Expressive esta funcionando atraves de 
um VHOST, e com isso podemos seguir em frente. 


5.4 Conhecendo a estrutura do Zend Expressive 


Agora que ja fizemos as configurações necessárias, 
podemos conhecer a estrutura do Zend Expressive e seus 
principais arquivos. Abra o nosso projeto  livro-zend- 
expressive com a sua IDE e vamos analisar a estrutura do 
microframework. 


tl livro-zend-expressive 








Figura 5.13: Estrutura do Zend Expressive 


Como podemos ver na imagem anterior, a estrutura de 
pastas do Zend Expressive é relativamente pequena e 
simples. Mas o que significa cada uma dessas pastas? E 
isso que veremos a seguir: 


e bin - esse diretório contém arquivos executáveis via 
terminal. Por exemplo, se você expandir esse 
diretório, você vera um arquivo chamado clear- 
config-cache.php , responsável por limpar o cache de 
configuração do microframework. Para utilizá-lo, 
basta você entrar no diretório raiz do projeto e 
executar o comando php bin/clear-config- 
cache.php . Você poderá criar qualquer executável 
dentro dessa pasta. 


e config - esse diretório é muito importante para o 
funcionamento do Zend Expressive, porque ele 
contém arquivos de configuração do 
microframework. Arquivos de configuração de banco 
de dados e rotas também entram nesse diretório. 


e config/autoload - contém arquivos de configuração 
que são carregados automaticamente com o 
microframework, como as configurações de 
carregamentos de middlewares, helpers, factories 
etc. 


e config/autoload/dependencies.global.php - é um 
arquivo que possui algumas configurações de modo 
global que são utilizadas por todo o microframework, 
como o cache de configurações, por exemplo. 


config/autoload/development.local.php - esse 
arquivo contém configurações que são utilizadas 
apenas em ambiente de desenvolvimento, como 
manipuladores de erros, por exemplo. Outro ponto 


importante é que esse arquivo não deve ser 
versionado. 


config/autoload/development.local.php.dist - é o 
mesmo arquivo que o anterior, porém com a 
extensão .dist no final. Essa extensão informa que 
o arquivo é um modelo e pode ser versionado, assim 
o desenvolvedor que atualizar o projeto deve copiar 
esse arquivo e retirar a extensão .dist . 


config/autoload/local.php.dist - também é um 
arquivo de modelo e para usá-lo basta renomeá-lo 
removendo a extensão .dist . Nele, você pode 
utilizar dados locais como usuários e senhas. 


config/autoload/zend-expressive.global.php - é 
um arquivo de configuração global, onde podemos 
habilitar ou desabilitar o cache de configuração de 
toda a aplicação e ainda definir um modelo de 
template para respostas de erros. 


config/config.php - contém as | principais 
configurações da aplicação, realizando o 
carregamento das demais configurações citadas, 
além de definir o diretório para gravação de cache, 
registrar configurações como tipo de rota, tipo de 
template etc. É um arquivo muito importante para o 
microframework. 


config/container.php - esse é outro arquivo muito 


importante, responsável por carregar todas as 
configurações através do serviço de injeção de 
dependência. 


config/development.config.php - esse é um 
arquivo responsável por permitir a ativação do modo 
de desenvolvimento, como debug e cache. 


r 


config/development.config.php.dist - é 
exatamente como o arquivo anterior, com a 
diferença de que possui a extensão .dist , ou seja, 
é um arquivo que serve como modelo. 


config/pipeline.php - esse arquivo também é muito 


importante e é responsável por realizar a 
inicialização dos middlewares globais da aplicação. 


config/routes.php - esse arquivo é simplesmente 
responsável por conter todas as rotas da aplicação, 
ou seja, toda vez que for necessário criar uma nova 
rota, é nesse arquivo que vamos mexer. É um 
arquivo extremamente importante, atente-se a ele. 


data - é o diretório responsável por conter arquivos 
de cache, diagramas etc. É nesse diretório que 
devemos salvar os caches da aplicação, como os 
caches do Doctrine. Veremos na prática a utilização 
desse diretório, não se preocupe. 


public - simplesmente contém o arquivo index.php , 
que é responsável por realizar a inicialização da 
aplicação. Quando chamarmos uma rota da 
aplicação, esse é o primeiro arquivo a ser executado 
pelo servidor. 


src (source) - esse diretório deverá conter todos os 
arquivos que serão criados para o desenvolvimento 
da aplicação. Arquivos como entidades, repositórios, 
validators, middlewares, deverão estar dentro dele. 


src/App - é o nome do módulo que padrão que o 
Zend Expressive criou. Dentro dele há um outro 
diretório chamado src , além de um diretório 
chamado templates , que veremos com mais 
detalhes adiante. 


src/App/src - basicamente é o mesmo 
funcionamento do diretório src principal, e deverá 
conter todas as classes referentes ao módulo. 


src/App/src/Handler - esse diretório funciona como 
o diretório controller do Zend Framework e de 
outros frameworks. O nome do diretório é flexível: se 
desejar chamar de "Action" por exemplo, você pode 
realizar essa alteração sem nenhum problema. Nós 
veremos mais sobre os diretórios que criaremos no 
decorrer deste livro. 


src/App/src/ConfigProvider.php - cada módulo 
criado deve conter esse arquivo, ele é responsável 
por realizar a inicialização de arquivos como 
services, factories, handlers etc. Trabalharemos 
bastante nesse arquivo no decorrer deste livro. 


r 


src/App/templates - esse diretório é responsável 
por conter todas as views da aplicacáo, incluindo 
templates de erros e o layout padráo. 


test - como o próprio nome sugere, é uma pasta que 


contém os testes de unidade e testes funcionais da 
aplicação. Todo e qualquer tipo de teste que for 
escrito para a aplicação deve ser criado dentro 
dessa pasta, respeitando a hierarquia de diretórios 
contido dentro da pasta src. 


vendor - esse diretório contém todas as bibliotecas 
utilizadas pela aplicação, ou seja, é um diretório 
criado pelo (Composer quando o instalamos, 
contendo todas as bibliotecas necessárias. Se 
futuramente for necessário realizar a inclusão de 
uma nova biblioteca, o Composer a salvará nesse 


diretório. 


composer.json - é um arquivo que o Composer lê 
para fazer a instalação ou atualização de bibliotecas. 
Basicamente é um arquivo no formato JSON 
contendo alguns pares (chave-valor) que o 
Composer lê, interpreta e executa uma determinada 
ação. Todas as bibliotecas utilizadas pela aplicação 
deverão estar presentes nesse arquivo. 


composer.lock - sempre que você for realizar a 
instalação de uma nova biblioteca em sua aplicação, 
o (Composer atualizará as informações nesse 
arquivo. Assim, quando outro desenvolvedor ou até 
mesmo você configurar o projeto em outro local, as 
versões exatas das bibliotecas serão instaladas, 
evitando erros ocasionados por bibliotecas ou 
versões diferentes. 


phpcs.xml.dist - esse é um arquivo de configuração 
utilizado para a padronização de códigos utilizando a 
PSR-2. 


e phpunit.xml.dist - arquivo de configuração de 
testes com o PHPUnit, quando for utilizá-lo renomeie 
para phpunit.xml 


Essa é a estrutura do Zend Expressive. Como podemos 
ver, não é uma estrutura complexa. Em um primeiro 
momento, ela pode ser confusa, principalmente se esse é 
o seu primeiro contato com framework, mas não se 
preocupe, porque vamos trabalhar muito utilizando essa 
estrutura e você se adaptará com facilidade. 


Conclusão 


Neste capítulo, vimos como clonar e configurar o Zend 
Expressive em nosso ambiente de desenvolvimento e 
ainda conhecemos um pouco de sua estrutura. Com isso, 
estamos aptos a iniciar o desenvolvimento do nosso 
projeto. No próximo capítulo, vamos criar nosso banco de 
dados, que será utilizado pela nossa aplicação e também 
configuraremos o ORM Doctrine para que possamos criar 
nossas entidades e nossos repositórios. Então, siga em 
frente. :) 


CAPÍTULO 6 
Configurando o Doctrine ORM e 
gerando entidades 


Antes de prosseguirmos, é necessário que você acesse o 
link https://is.gd/hndH6SJ e faça o download do esquema 
básico do banco de dados que será utilizado pela 
aplicação. Caso você tenha algum problema com o link, 
você poderá baixar O arquivo 
livro zend expressive db.sql diretamente do repositório 
do projeto no link a seguir: https://github.com/jhones/livro- 
zend-expressive/tree/master/data/sql/. Não é um banco 
grande e complexo, mas pequeno e simples, que servirá 
para o nosso projeto de API. 


Após ter efetuado o download do arquivo, importe-o para 
o banco de dados porque vamos utilizá-lo junto para 
gerarmos as entidades mais adiante neste capítulo. 


6.1 Integrando o Doctrine ao Zend Expressive 


Antes de mais nada, primeiramente vamos clonar o 
Doctrine em nosso projeto utilizando o Composer. Para 
isso execute o comando a seguir na raiz do nosso projeto 
livro-zend-expressive : 


composer require doctrine/orm 


Se tudo ocorreu bem, você deverá ter uma saída 
semelhante à mostrada na imagem a seguir: 
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Figura 6.1: Clonando o Doctrine ORM 


Apos o clone do Doctrine ter sido bem-sucedido, devemos 
criar um arquivo de configuração chamado cli- 
config.php dentro do diretório config com o seguinte 
conteúdo: 


<?php 
use Doctrine\ORM\Tools\Console\ConsoleRunner ; 
use Doctrine\ORM\EntityManager ; 


require _ DIR__ . '/../vendor/autoload.php'; 


/** @var \Interop\Container\ContainerInterface $container 
*/ 

$container = require __DIR__ 

'/../config/container.php'; 


/** @var \Doctrine\ORM\EntityManager $em */ 
$em = $container->get(EntityManager::class); 


return ConsoleRunner: :createHelperSet ($em) ; 


O código anterior é responsável por carregar as 
configurações do Doctrine para que possamos utilizá-lo 


através do terminal. Isso é necessário pois mais adiante, 
neste capítulo, realizaremos a geração das entidades com 
base nas nossas tabelas do banco de dados. 


y 


O próximo passo é criarmos o arquivo chamado 
doctrine.local.php dentro do diretório config/autoload 
com o seguinte conteúdo: 


<?php 
return [ 


'doctrine' => [ 
'connection' => [ 


‘orm' => [ 
"auto generate proxy classes' => true, 
'proxy dir' => 
'data/cache/Proxy', 
'proxy_namespace' => 'Proxy', 
'underscore_naming_strategy' => true, 


l, 
'orm_default' => [ 
'driverClass' => 
Doctrine\DBAL\Driver\PDOMySql\Driver::class, 
'host' => 'localhost', 
'port' => 3306, 
'user' => 'root', 
'password' => 'root', 
'dbname' => 'livro zend expressive db', 
'driverO0ptions' => [ 
\PDO: : MYSQL ATTR INIT COMMAND => "SET 
NAMES 'UTF8'" 


1, 
1, 


IE 


O arquivo anterior é muito importante porque define as 
configurações de acesso ao banco de dados, além de 
fazer a gravação de proxies, que são uma espécie de 
cache para agilizar as consultas. Perceba que a chave 

proxy dir , contida dentro da chave orm , indica o 
diretório em que esses caches serão armazenados, logo, 
é necessário criá-lo e conceder permissão de escrita. 
Para isso, execute os comandos a seguir na raiz do seu 
projeto: 


mkdir data/cache 
mkdir data/cache/Proxy 
chmod -R 777 data/ 


Com os comandos anteriores, você criará o diretório 
cache € Proxy , já concedendo permissão 777, ou seja, 
acesso total para este diretório. A chave orm default 
contém as configurações de acesso ao banco de dados 
que você criou e cujas tabelas importou. No meu caso, a 
configuração contida no código está correta, você deve 
alterá-la para adequar-se de acordo com a sua 
configuração local. 


MAS AFINAL O QUE É UMA FACTORY? 


Uma Factory ou Fábrica é um padrão de projeto 
responsável por criar objetos sem expor a criação 


lógica para o cliente, ou seja, ele permite criar objetos 
sem que o cliente saiba como é o processo de 
criação. No Zend Expressive ele será muito utilizado. 





Por fim, deveremos criar uma Factory para fazer o 
carregamento das configurações do Doctrine no Zend 


Expressive e chamá-la no arquivo de configuração 

dependencies.global.php . Primeiramente, vamos criar a 
nossa Factory . Dentro do diretório src que está dentro 
de app, crie os diretórios Doctrine € Factory e, em 
seguida, uma classe chamada DoctrineormFactory . Nesse 
momento sua estrutura de diretórios deve estar parecida 
com a imagem a seguir: 
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Figura 6.2: Estrutura de diretórios e criação da classe DoctrineORMFactory 


Abra a classe DoctrineORMFactory e Insira o conteúdo a 
seguir dentro dela: 


<?php 
declare(strict types=1); 


namespace App\Doctrine\Factory; 


use Doctrine\Common\Annotations\AnnotationReader ; 
use Doctrine\Common\Annotations\AnnotationRegistry; 
use Doctrine\ORM\Configuration; 

use Doctrine\ORM\EntityManager ; 

use Doctrine\ORM\Mapping\UnderscoreNamingStrategy; 
use Interop\Container\ContainerInterface; 

use Doctrine\ORM\Mapping\Driver\AnnotationDriver ; 


Class DoctrineORMFactory 
{ 

public function __invoke(ContainerInterface 
$container): EntityManager 

{ 


$config = $container->has('config') ? $container - 


>get('config') : []; 
$proxyDir = (isset($config['doctrine' ] 
['connection' ]['orm']['proxy_dir'])) ? 
$config['doctrine']['connection']['orm'] 
['proxy_dir'] : 'data/cache/EntityProxy'; 
$proxyNamespace = (isset($config['doctrine'] 
['connection']['orm']['proxy_namespace'])) ? 
$config[ 'doctrine']['connection']['orm' ] 
[ 'proxy_namespace'] : 'EntityProxy'; 
$autoGenerateProxyClasses = 
(isset($config['doctrine']['connection']['orm' ] 
[ 'auto_generate_proxy_classes'])) ? 
$config[ 'doctrine']['connection']['orm' ] 
[ 'auto_generate_proxy_classes'] : true; 
$underscoreNamingStrategy = 
(isset($config['doctrine']['connection']['orm' ] 
[ 'underscore_naming_strategy'])) ? 
$config[ 'doctrine']['connection']['orm'] 
[ 'underscore_naming_strategy'] : true; 


$doctrine = new Configuration(); 
$doctrine->setProxyDir ($proxyDir); 
$doctrine->setProxyNamespace($proxyNamespace); 
$doctrine- 
>setAutoGenerateProxyClasses(SautoGenerateProxyClasses); 
if (SunderscoreNamingStrategy) { 
$doctrine->setNamingStrategy (new 
UnderscoreNamingStrategy()); 


} 


AnnotationRegistry::registerFile(_ DIR__ 
"J..S..4/../7../7../vendor/doctrine/orm/lib/Doctrine/ORM/Map 
ping/Driver/DoctrineAnnotations.php' ); 

$driver = new AnnotationDriver ( 

new AnnotationReader(), 
LOR . "Prada ef sd STCCENELEY' ] 


); 


$doctrine->setMetadataDriverImpl($driver); 


return EntityManager::create($config[ 'doctrine'] 
['connection']['orm default'], $doctrine); 


} 
} 


Vamos entender a classe DoctrineoRmFactory . Ela possui 
a responsabilidade de setar as configurações para o 
funcionamento do Doctrine, definindo o diretório em que 
as entidades estarão inclusas, assim como as 
configurações para geração de proxy das entidades. 
Perceba ainda que essa classe retorna um objeto 
EntityManager que será utilizado pela nossa aplicação. 


Há dois pontos importantes exclusivos do PHP 7: 
primeiramente, o código declare(strict_types=1) , que 
informa que nesse arquivo será utilizado o modo estrito do 
PHP 7. Isso significa que estamos informando ao PHP 
para ser rigoroso quanto à tipificação de parâmetros, 
retornos etc. Dessa forma, também podemos definir o tipo 
de retorno dos métodos e dos parâmetros. 


Perceba que estamos utilizando o método _ invoke 

Todas as Factories que criarmos deverão ter 
obrigatoriamente esse método mágico. Ele é chamado 
quando um determinado script fizer uma tentativa de 
chamada a um objeto como uma função. Você pode 
conhecer mais sobre o método  _ invoke no link da 
documentacáo oficial: 
http://php.net/manual/pt BR/language.oop5.magic.phpfob 


ject.invoke/. 


Outro ponto a ser considerado é o tipo de retorno do 
método _ invoke , que é especificado com : (dois 


pontos) após o parêntese de fechamento do método. O 
tipo de retorno definido nesse caso é EntityManager , que 
indica que o retorno deve ser obrigatoriamente desse tipo, 
ou seja, deve ser uma instância de EntityManager criada 
pelo Doctrine. 


Nosso próximo passo é registrar nossa Factory no 
arquivo de configuração config/dependencies.global.php . 
Abra esse arquivo e insira o trecho de código a seguir 
dentro da chave Factories do array: 


Doctrine\ORM\EntityManager::class => 
\App\Doctrine\Factory\DoctrineORMFactory::class 


Nesse momento, O seu arquivo 
config/dependencies.global.php deve estar parecido com 
o da imagem a seguir: 


dependencies global. php 





Figura 6.3: Registrando a Factory DoctrineORMFactory 


Perceba que estamos informando que o nome da classe 

Doctrine\ORM\EntityManager::class referencia a nossa 
Factory App\Doctrine\Factory\DoctrineORMFactory::class , 
que retorna a instância de  EntityManager com as 
configurações setadas do Doctrine. 


Nosso último passo é verificarmos se a integração do 
Doctrine foi realizada com sucesso, o que pode ser feito 
testando a conexão. Se o Doctrine retornar o objeto 

EntityManager com as informações da conexão com o 
banco de dados, então a integração do Doctrine foi bem- 
sucedida. Para testarmos, vamos criar uma nova classe 
de handler chamado  TestDoctrineconnectionHandler 
dentro do diretório src/App/src/Handler , conforme mostra 
a imagem a seguir: 
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Figura 6.4: Criando o handler TestDoctrineConnectionHandler 


Em seguida, abra o arquivo e coloque o conteúdo a seguir 
dentro dele: 


<?php 
declare(strict types=1); 


namespace App\Handler; 


use Doctrine\ORM\EntityManager ; 

use Psr\Http\Message\ResponseInterface; 

use Psr\Http\Message\ServerRequestiInterface; 
use Psr\Http\Server\RequestHandlerInterface; 
use Zend\Diactoros\Response\JsonResponse; 


Class TestDoctrineConnectionHandler implements 
RequestHandlerInterface 
{ 
per 
* (var EntityManager 
dd 
private $em; 


public function _ construct(EntityManager Sem) 


{ 


$this->em = $em; 


per 
* @param ServerRequestInterface $request 
* (return ResponseInterface 
“+ 
public function handle(ServerRequestInterface 
$request): ResponseInterface 
{ 
$isConnected = $this->em->getConnection()- 
>connect(); 
return new JsonResponse(['doctrine_is_connected' 
=> $isConnected]); 
} 
} 


A classe TestDoctrineConnectionHandler é como um 
controller da arquitetura MVC. Quando definirmos a rota 
para utilizar esse recurso, é para essa classe que vamos 


apontar a rota - veremos isso no próximo passo. Essa 
classe realiza a implementação da | interface 
Psr\Http\Server\RequestHandlerInterface , que traz 
consigo o método handle com o parâmetro grequest do 
tipo Psr\Http\Message\ServerRequestiInterface . Perceba 
também que o tipo de retorno esperado pelo método é o 
Psr\Http\Message\ResponseInterface , obtido através da 
instância da classe Zend\Diactoros\Response\JsonResponse . 
Essa classe vai retornar as informações que estão 
contidas no array em formato JSON. Não ficou claro? 
Quando executarmos o teste você entenderá melhor. 


Nossa classe TestDoctrineconnectionHandler possui um 
método construtor que é responsável por passar como 
dependência um objeto EntityManager e essa 
dependência será passada pela Factory que criará para a 
nossa classe. 


A classe TestDoctrineConnectionHandler deve ser parecida 
com a da imagem a seguir: 


TestDoctrnineConnechonHandier.php 
<?php 
declare(strict ty 
namespace Api 
use [ 
use Psr\Http 
use Ps 
use 


use ceng 


ler implements Real 


private 


public function construct(EntityManager 


public function handle(ServerRequestInterface 


getConnectiont )->connect() 
return new JsonResponse(l => 





Figura 6.5: Conteudo da classe TestDoctrineConnectionHandler 


Seguindo em frente, crie um diretório chamado Factory 
dentro do diretório Handler , e dentro dele crie uma classe 
chamada TestDoctrineconnectionHandlerFactory , que sera 
responsável por realizar a injeção de dependência para a 
nossa classe TestDoctrineConnectionHandler . Sua 
estrutura de diretorios deve ser parecida com a da 
imagem a segulr: 


Y Ba livro-zend-expressive 





Figura 6.6: Criando o diretório Factory e a classe 
TestDoctrineConnectionHandlerFactory 


Criamos o diretório Factory para deixar nossa estrutura e 
código mais organizados, assim separamos as Factories 
dos handlers. Em seguida, abra a nossa classe 

TestDoctrineConnectionHandlerFactory e coloque o 
seguinte código nela: 


<?php 
declare(strict types=1); 
namespace App\Handler\Factory; 


use App\Handler\TestDoctrineConnectionHandler ; 
use Psr\Container\Containerinterface; 


Class TestDoctrineConnectionHandlerFactory 


{ 


public function | invoke(ContainerInterface 
$container): TestDoctrineConnectionHandler 


{ 


$em = $container - 
>get('Doctrine\ORM\EntityManager' ); 
return new TestDoctrineConnectionHandler ($em); 


} 


Ja foi dito anteriormente que todas as Factories que 
criarmos deverão ter obrigatoriamente o metodo 
__invoke , até aí nenhuma surpresa. Agora perceba que, 
nesta classe, estamos utilizando o método get do objeto 
ContainerInterface . Esse método é o responsável por 
recuperar a nossa configuração registrada no arquivo de 
configuração config/dependencies.global.php . 


Você lembra que informamos la no arquivo de 
configuração que a chave  Doctrine\ORM\EntityManager 
referencia a Factory que criamos para o Doctrine? Pois 
bem, nosso handler atual possui como dependência um 
objeto do tipo Entitymanager e é exatamente isso que 
estamos fazendo, ou seja, estamos recuperando o objeto 
EntityManager através do nosso  serviceManager € 
estamos passando esse objeto para o nosso handler 
TestDoctrineConnectionHandler . 


Note mais uma vez, que estamos usando o modo estrito 
do PHP 7 e também estamos informando ao método que 
o tipo de retorno esperado é um objeto do tipo 

TestDoctrineConnectionHandler . Nesse momento, sua 
Classe TestDoctrineConnectionHandlerFactory deve ser 
parecida com a da imagem a seguir: 


TestDoctrineConnechontiandier Factory.php 





Figura 6.7: Factory TestDoctrineConnectionHandlerFactory 


Nosso próximo passo é criar a rota que vamos utilizar 
para testarmos a conexão com o Doctrine. Para isso, abra 
O arquivo config/routes.php e coloque o seguinte código 
dentro da ciosure (função anônima) embaixo da última 
rota criada: 


$app->get('/api/test-doctrine-connection', 
App\Handler\TestDoctrineConnectionHandler::class, 
'api.test-doctrine-connection'); 


Nesse momento, seu código deve ser parecido com o 
demonstrado a seguir: 


<?php 

declare(strict types=1); 

use Psr\Container\ContaineriInterface; 
use Zend\Expressive\Application; 


use Zend\Expressive\MiddlewareFactory; 


return function (Application $app, MiddlewareFactory 
$factory, ContainerInterface $container) : void { 


$app->get('/', App\Handler\HomePageHandler::class, 
‘home'); 

$app->get('/api/ping', 
App\Handler\PingHandler::class, 'api.ping'); 

$app->get('/api/test-doctrine-connection', 
App\Handler\TestDoctrineConnectionHandler::class, 
'api.test-doctrine-connection'); 


$ 


Perceba que é um arquivo bastante simples, e o único 
ponto a ser observado é que todas as rotas criadas 
devem estar dentro da funcáo anónima. Para criarmos 
uma rota, ela deve ter obrigatoriamente o tipo e o 
middleware, que no caso é o nosso handler 

App\Handler\TestDoctrineConnectionHandler . O terceiro 
parâmetro do método get é opcional e nele 
especificamos o nome para uma determinada rota, que no 
nosso caso chamamos de api.test-doctrine-connection . 


Nosso último passo é registrar o nosso handler e a 
Factory do nosso handler na classe 

src/App/src/ConfigProvider.php para que possamos 
realizar uma chamada para a rota que acabamos de criar. 
Abra O arquivo src/App/src/ConfigProvider.php e coloque 
o código a seguir no método getDependencies dentro da 
chave Factories do array retornado pelo método: 


Handler\TestDoctrineConnectionHandler::class => 
Handler\Factory\TestDoctrineConnectionHandlerFactory::cla 
SS 


O seu metodo getDependencies deve ser parecido com o 
código demonstrado a seguir: 


<?php 
JEX 


* Returns the container dependencies 
RA 
public function getDependencies() : array 


{ 


return [ 
'invokables' => [ 
Handler\PingHandler::class => 
Handler\PingHandler::class, 


l, 
'factories' => [ 
Handler\HomePageHandler::class => 
Handler\HomePageHandlerFactory::class, 
Handler\TestDoctrineConnectionHandler::class 
=> 
Handler\Factory\TestDoctrineConnectionHandlerFactory::cla 
SS, 


]; 
} 


Perceba que registramos tanto O 
TestDoctrineConnectionHandler quanto a sua Factory 
TestDoctrineConnectionHandlerFactory , que realiza a 

injeção de dependência do objeto Entitymanager do 

Doctrine. 


Finalmente, finalizamos a parte da criação. Pode parecer 
complicado à primeira vista, mas na verdade é apenas 
trabalhoso, pois tudo o que fizermos no Zend Expressive 
tem que ser especificado e registrado. Não se preocupe 
porque logo mais você estará acostumado com esse 
trabalho e conseguirá fazer seus códigos sem 


dificuldades. 


Agora que finalizamos, devemos testar nossa rota para 
termos a certeza de que o Doctrine está configurado 


corretamente. Para realizar esse teste, você pode utilizar 
um cliente que efetua requisições como o Postman, SOAP 
Ui etc. Você pode utilizar até mesmo o navegador, já que 
a rota é do tipo cet . Isso funcionará sem nenhum 
problema, ok? Em meu caso, estou utilizando o Postman 
para realizar os testes. Para testar, abra o cliente que 
você utilizará e digite http://livro-zend- 
expressive.dev/api/test-doctrine-connection O, em 
seguida, tecle ENTER, O resultado deve ser semelhante ao 
mostrado na imagem a seguir: 


Como UTILIZAR O POSTMAN 


Para utilizar o Postman, basta você fazer o download 
do App no link https://www.getpostman.com/apps/ de 
acordo com a sua plataforma, instalar ou 


descompactar. Após a instalação ou 
descompactação, basta abrir o Postman e colocar a 
URL desejada, selecionar o tipo de requisição 
desejada GET, POST, PUT, PATCH, DELETE etc. e 
clicar em send. 
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Figura 6.8: Resultado do teste de conexão do Doctrine 


Se o resultado obtido for semelhante ao da imagem 
anterior, então parabéns! Isso significa que você 
configurou e integrou corretamente o Doctrine ao seu 
projeto. Perceba que a chave doctrine is connected é 
igual a true , indicando que a conexão do Doctrine com o 
banco de dados foi bem-sucedida. Se a sua resposta tiver 
sido diferente de true entáo revise os passos até aqui 
com calma e atencáo e tente novamente, que tudo dará 
certo :). 


6.2 Gerando entidades automaticamente 


Com o nosso banco de dados devidamente criado e 
importado, e com o Doctrine devidamente integrado ao 
Zend Expressive, chegou a hora de gerarmos as 
entidades com base em nossas tabelas do banco de 
dados. 


O Doctrine nos permite gerar as entidades de forma 
rápida e é isso que faremos. Se você ainda está um 
pouco confuso sobre o que significa uma “entidade” ou 
entity , imagine que é transformar as tabelas do nosso 
banco de dados em classes PHP. É muito semelhante a 
uma model da arquitetura MVC. 


Para gerarmos as entidades, entre na raiz do nosso 
projeto e execute o comando a seguir: 


php vendor/bin/doctrine orm:convert-mapping --from- 
database annotation src/App/src/Entity/ 


O comando anterior informa ao Doctrine para gerar as 
entidades por meio do banco de dados e salvá-las no 
diretório src/App/src/Entity . Caso o diretório ainda não 
exista, então crie-o e execute o comando novamente. 
Após a execução do comando, você deverá visualizar 
uma saída semelhante à mostrada na imagem a seguir: 





Figura 6.9: Gerando entidades com o Doctrine 


A imagem mostra que as entidades foram geradas com 
sucesso, e se abrirmos o diretório Entity poderemos ver 
as entidades que foram geradas, conforme mostra a 
imagem a seguir: 
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Figura 6.10: Entidades geradas dentro do diretorio Entity 
Conclusao 


Chegamos ao final de mais um capitulo, em que foi 
demonstrado como integrar e configurar o Doctrine ORM 
no Zend Expressive. Tambem vimos como criar e registrar 





um novo handler e definimos uma nova rota para que 
pudéssemos testar se a conexão do Doctrine com o 
banco de dados foi efetuada com sucesso. 


A partir do próximo capítulo, vamos iniciar uma série de 
três capítulos nos quais vamos melhorar as entidades que 
foram geradas pelo Doctrine. Vamos criar os métodos 
getters € setters , utilizar um componente do Zend 
Framework chamado Zend Hydrator, que fara com que 
as nossas entidades possam ter o conteudo setado de 
forma mais rápida e eficaz, e também vamos utilizar 
alguns componentes para criação de senha, tornando-a 
mais segura. Então, siga em frente e vamos nessa! 


CAPÍTULO 7 
Melhorando a entidade TbTipoUsuario 


No capítulo anterior geramos as entidades utilizando o 
Doctrine, porém precisamos melhorá-las, criando os 
métodos básicos de uma entidade, definindo o repositório 
de cada uma etc. Antes de iniciarmos as modificações em 
nossas entidades, nós vamos conhecer e integrar o 
componente Zend Hydrator em nossa aplicação. 


O QUE É O ZEND HyDRATOR? 


É um componente do Zend Framework responsável 
por realizar a hidratação de dados, o que chamamos 


de popular um objeto com determinados dados. O 
Zend Hydrator é simples e fornece métodos para 
hidratar/popular o objeto e também fornece para 
extrair seus dados. 





Vale ressaltar que vamos utilizar o Zend Hydrator em 
nosso projeto porque ele facilitará nossa vida tanto para 
popular os objetos quanto para extrair os dados do objeto. 


Então vamos instalar o componente. Para isso, abra o seu 
terminal, vá até a raiz do projeto e execute o seguinte 
comando para realizar a instalação: 


composer require zendframework/zend-hydrator 


Após executar o comando anterior, aparecerá uma 
mensagem para que você selecione se deseja injetar o 


Zend Hydrator no arquivo de configuração ou não. 
Selecione a opção 1 para injetar o Zend Hydrator no 
arquivo de configuração e, em seguida, tecle ENTER para 
prosseguir com a instalação. 


Em seguida, será exibida uma pergunta informando se 
você deseja relembrar a opção de injetar o componente 
no arquivo de configuração para as próximas instalações 
de componentes, informe y (sim) e tecle ENTER para 
prosseguir com a instalação. Após a execução desses 
passos, você deverá visualizar uma saída semelhante à 
exibida na imagem a seguir: 





Figura 7.1: Clonando e registrando o componente Zend Hydrator 


Excelente, o Zend Hydrator está integrado ao Zend 
Expressive e podemos seguir em frente. Uma 
dependência atual do Zend Hydrator é o Zend Filter, então 
devemos instalá-lo também. Internamente, o Zend 
Hydrator utiliza o componente Zend Filter para realizar a 
filtragem dos dados enviados para serem hidratados. 


O QUE É O ZEND FILTER? 


É um componente do Zend Framework responsável 
por realizar a filtragem de dados, como transformar 


uma string em letras maiúsculas ou minúsculas. O 
Zend Filter é simples e fornece métodos para realizar 
o tratamento adequado. 





Para instalar o componente Zend Filter, execute o 
comando a seguir: 


composer require zendframework/zend-filter 


Novamente, após executar o comando anterior, aparecerá 
uma mensagem para que você selecione se deseja injetar 
o Zend Filter no arquivo de configuração ou não. 
Selecione a opção 1 para injetar o Zend Filter no arquivo 
de configuração e, em seguida, tecle ENTER para 
prosseguir com a instalação. 


Após a instalação bem-sucedida do componente Zend 
Filter você deverá ver uma saída semelhante à mostrada 
na imagem a seguir: 





Figura 7.2: Clonando e registrando o componente Zend Filter 


Agora que temos a dependência do Zend Hydrator 
instalada em nossa aplicação, podemos seguir em frente 
na melhoria de nossas entidades. 


A primeira entidade em que vamos fazer nossas 
alterações sera a TbTipoUsuario , que é responsável pelos 
tipos de usuários da aplicação. Abra essa entidade em 
sua IDE. Perceba que ela não possui nenhum namespace 
e nenhum método criado. Perceba que o nome da 
entidade é exatamente o mesmo nome da tabela que foi 
criada no banco de dados, e as propriedades da entidade 
são exatamente os campos da tabela no MySQL. O que 
faremos para todas as entidades será: 


Alterar o nome da entidade; 
Definir modo estrito do PHP 7; 
Definir namespace; 

Alterar nome das propriedades; 
Definir repositório; 

Definir métodos. 


Então, seguindo essa linha de raciocínio, vamos para o 
primeiro item da lista. 


Alterando o nome da entidade 


Edite o nome da entidade e coloque como Tipousuario . 
Em seguida, abra-a e altere também o nome da classe 
para TipoUsuario . Após as alterações, ela deve ser 
semelhante à mostrada na imagem a seguir: 





Figura 7.3: Alterando nome da entidade e da classe para TipoUsuario 


Definindo o modo estrito do PHP 7 


Antes de seguirmos, vamos habilitar o modo estrito do 
PHP 7 inserindo o código a seguir logo após a tag de 
abertura do PHP: 


declare(strict types=1); 


Após habilitar o modo estrito da sua entidade, ela deve 
estar parecida com a da imagem a seguir: 


É TipoUsuario.php 


Tipolsuario 





Figura 7.4: Habilitando o modo estrito do PHP 7 na entidade TipoUsuario 
Definindo o namespace 


Nosso próximo passo é definir o namespace da entidade. 
Como você pôde perceber, as entidades não possuem um 
namespace após sua geração pelo Doctrine. Então, 
vamos defini-lo. Coloque o código a seguir no começo da 
sua entidade, antes do nome da classe e até mesmo 
antes da declaração use : 


namespace App\Entity; 


Após essa alteração, sua entidade deve ter uma definição 
de namespace semelhante à da imagem a seguir: 


{3 TipoUsuario.php 


App\Entity 


Tipolsuario 





Figura 7.5: Definindo namespace para a entidade TipoUsuario 
Alterando o nome das propriedades 


Agora temos que alterar o nome das propriedades da 
entidade para torná-las mais legíveis e de mais fácil 
compreensão. Para isso, faremos conforme o código a 
seguir: 


pea 
* @var int 
* @ORM\Column( name="id", type="integer", nullable=false) 
* @ORM\Id 
* @ORM\GeneratedValue(strategy="IDENTITY" ) 


*/ 
private $id; 


Pen 

* (var string 

* (00RMNColumn(name="nm tipo", type="string", length=45, 
nullable=false, options=["comment"="Tipo">) 

i 
private $tipo; 


q. 

* @var bool 

* 

* @ORM\Column(name="sSt_ativo", type="boolean", 
nullable=false, options={"default"="1", "comment"="Esta 
ativo? 

O - Nao 
1 - Sim"}) 

eS 

private $ativo = true; 


per 

* @var \DateTime 

* 

* @ORM\Column(name="dt_criado_em", type="datetime", 
nullable=false, options= 
{"default"="CURRENT_TIMESTAMP", "comment"="Data de 
criação") 

27 
private $criadoEm = ' CURRENT TIMESTAMP'; 


pa 

* @var ADateTime|null 

* 

* @ORM\Column(name="dt_alterado_em", type="datetime", 
nullable=true, options={"comment"="Data de alteracao"}) 


nd 
private $alteradoEm; 


para 
* @var \DateTime|null 


* 


* @ORM\Column(name="dt_deletado_em", type="datetime", 
nullable=true, options={"comment"="Data de exclusao"}) 
"y 
private $deletadoEm; 


Até aqui nada demais, apenas estamos renomeando as 
propriedades para que fiquem mais legíveis. As 
propriedades alteradas de sua entidade devem ser 
semelhantes às da imagem a seguir: 





Figura 7.6: Renomeando propriedades da Entidade TipoUsuario 


Nosso próximo passo é definir o repositório para a nossa 
entidade. 


Definindo o repositório na entidade 


7 


Um repositório é uma classe responsável por conter 
métodos que se comunicam de forma mais direta com o 
banco de dados. Como estamos utilizando o Doctrine, 
essa comunicação é realizada através da linguagem DQL 
(Doctrine Query Language), que nada mais é que o SQL, 
mas adaptado com algumas características do Doctrine. 


Definir um repositório para a nossa entidade é bem 
simples e se dá por meio de annotation (anotação). 
Coloque o código a seguir em sua entidade, substituindo a 
annotation @oRrM\Entity , que está localizada acima do 
nome da classe: 


@ORM\Entity(repositoryClass="App\Repositol 


Após a definição do repositório TipoUsuarioRepository sua 
entidade deve ser semelhante à mostrada na imagem a 
seguir: 


{> TipoUsuano.php 





Figura 7.7: Definindo repositório na entidade TipoUsuario 


Perceba que definimos o repositório com o namespace 
App\Repository\TipoUsuarioRepository , mas o diretório e a 
classe no momento não existem ainda. Faremos isso em 
nosso próximo capítulo, em que focaremos na criação dos 
repositórios das entidades, então não se preocupe. 


Definindo os métodos da entidade TipoUsuario 


Como foi dito anteriormente, as entidades que geramos 
pelo Doctrine não possuem métodos e é exatamente isso 
que faremos agora. O primeiro que faremos é o método 
construtor construct , no qual já aplicaremos o 
componente Zend Hydrator , responsável por setar os 
dados de forma automática quando a entidade for 
chamada. Coloque o código a seguir em sua entidade: 


use Zend\Hydrator\ClassMethods; 


Primeiramente, importe a classe — ClassMethods do 
componente Zend Hydrator em sua entidade. Lembre-se 
de que a declaração use deve ficar abaixo do namespace 
da classe, junto com as outras declarações use , 
conforme mostra a imagem a seguir: 


o TipoUsuario php 





Figura 7.8: Importando o Componente Zend Hydrator ClassMethods na 
Entidade TipoUsuario 


Após a importação da classe ClassMethods , defina o 
construtor da entidade como no código a seguir: 


public function __construct(array $data = []) 


{ 


$this->criadoEm = new \DateTime('now'); 
(new ClassMethods())->hydrate($data, $this); 
} 


Observe que ele possui como parâmetro um array de 
dados que não é obrigatório. Estamos instanciando a 
classe classMethods e, em seguida, já estamos chamando 
o método hydrate passando como parâmetros a variável 

$data e o Objeto $this , que referencia a própria 
entidade. O hydrate val comparar os métodos setters 
da nossa entidade com o nome das chaves enviadas no 
array de dados. A cada checagem bem-sucedida, o 

hydrate setará o valor contido na chave chamando 
automaticamente o método correspondente. Dessa forma, 
ao utilizarmos a entidade para setar valores, não 
precisaremos fazer: 


$tipoUsuario = new TipoUsuario(); 
$tipoUsuario->setTipo(); 
$tipoUsuario->setEmail(); 

Ps EF 


Outro ponto, se você perceber, é que estamos definindo 
que a propriedade $this->criadoEm já possuirá o objeto 
"DateTime do PHP setado com a data e hora atual em 
que a entidade for executada. 


Agora que definimos o método construtor, vamos definir 
os métodos getters e setters da nossa entidade. 
Observe atentamente o código a seguir, no qual estamos 
definindo os métodos juntamente com o tipo de retorno 
esperado: 


É ane 

* @return int 

y 
public function getId(): int 
{ 


return $this->id; 


Y Ex 
* @return string 
“T 
public function getTipo(): string 


{ 


return $this->tipo; 


É aan 
* @param string $tipo 
* @return TipoUsuario 
"r 


public function setTipo(string $tipo): 


{ 
$this->tipo = $tipo; 
return $this; 


es 
* (return bool 
=f 
public function isAtivo(): bool 


{ 


return $this->ativo; 


fen 
* @param bool $ativo 
* @return TipoUsuario 


TipoUsuario 


* ff 
public function setAtivo(bool $ativo): TipoUsuario 
{ 
$this->ativo = $ativo; 
return $this; 


per 
* (return \DateTime 
y 
public function getCriadoEm(): \DateTime 


{ 


return $this->criadoEm; 


/** 
* @return TipoUsuario 
Ef 
public function setCriadoEm(): TipoUsuario 
{ 
$this->criadoEm = new \DateTime('now'); 
return $this; 


pea 

* @return \DateTime|null 

E 
public function getAlteradoEm(): ?\DateTime 
{ 


return $this->alteradoEm; 


em 
* (return TipoUsuario 
e 
public function setAlteradoEm(): TipoUsuario 


{ 


$this->alteradoEm = new \DateTime('now'); 
return S$this; 


O ici 

* @return \DateTime|null 

wr 
public function getDeletadoEm(): ?\DateTime 
{ 


return $this->deletadoEm; 


per 
* (return TipoUsuario 
eL 
public function setDeletadoEm(): TipoUsuario 


{ 


$this->deletadoEm = new \DateTime('now'); 
return $this; 


} 


Perceba que os métodos setters possuem o retorno do 
tipo Tipousuario esperado. Isso significa que estamos 
trabalhando com interface fluente, ou seja, podemos 
chamar vários métodos setters sem a necessidade de 
chamar a variável do objeto como fizemos anteriormente: 


$tipoUsuario = new TipoUsuario(); 
$tipoUsuario->setTipo(); 
$tipoUsuario->setEmail(); 

per. swe 


Através da interface fluente, podemos chamar os métodos 
da seguinte maneira: 


$tipoUsuario = new TipoUsuario(); 
$tipoUsuario->setTipo() 


->setEmail() 
->setAtivo(); 
pen ERF 


Simples, não é mesmo? Perceba que os métodos 
getAlteradoEm € getDeletadoEm possuem o tipo de retorno 
?\DateTime . O ? no retorno indica que o retorno pode ser 

do tipo \DateTime OU null , isso porque em nosso banco 

de dados as colunas dt alterado em € dt deletado em 
não possuem preenchimento obrigatório. 


Se você observou atentamente os métodos criados, deve 
ter percebido que não possuímos o método setid . O 
motivo é que o campo id no banco de dados é 
autoincremento, ou seja, o valor será incrementado 
automaticamente. Por esse motivo, não criamos o método 
setId . 


Para finalizarmos, falta criarmos o método toArray que 
será responsável por pegar todos os dados da entidade e 
retorná-los em forma de array. Observe o código a seguir: 


pen 
* @return array 
“E 
public function toArray(): array 


{ 


return (new ClassMethods())->extract($this); 


} 


Perceba que estamos utilizando novamente a classe 

ClassMethods , mas dessa vez para retornar todos os 
dados do objeto em forma de array. O método extract da 
classe classMethods recebe como parâmetro um objeto, 
que no nosso caso é a própria entidade representada pelo 


objeto $this. 


Com isso, finalizamos as alterações em nossa entidade 
TipoUsuario , Você pode ver o código completo dela a 
seguir: 


<?php 
declare(strict types=1); 
namespace App\Entity; 


use Doctrine\ORM\Mapping as ORM; 
use Zend\Hydrator\ClassMethods; 


pa 
* TipoUsuario 


* 


* @ORM\Table(name="tb_tipo_usuario") 
@ORM\Entity(repositoryClass="App\Repository\TipoUsuarioRe 
pository") 

“a 
class TipoUsuario 
{ 

/** 
* @var int 
* @ORM\Column( name="id", type="integer", 
nullable=false) 
* @ORM\Id 
* @ORM\GeneratedValue(strategy="IDENTITY" ) 
al 
private $id; 


Pili 
* @var string 


* 


* @ORM\Column(name="nm_tipo", type="string", 
length=45, nullable=false, options={"comment"="Tipo"}) 
"7 
private $tipo; 


e. 
* @var bool 
x 
* (QOORMNColumn(name="st ativo", type="boolean", 
nullable=false, options=("default"="1","comment"="Está 
ativo? 


O - Não 
1 - SH”) 
=r 
private $ativo = '1'; 
SER 


* @var \DateTime 

* 

* @ORM\Column(name="dt_criado_em", type="datetime", 
nullable=false, options= 
{"default"="CURRENT_TIMESTAMP", "comment"="Data de 
criação") 

“7 

private $criadoEm = 'CURRENT TIMESTAMP'; 


per 

* @var \DateTime|null 

* 

* @ORM\Column(name="dt_alterado_em", 
type="datetime", nullable=true, options={"comment"="Data 
de alteracao"}) 

"y 

private $alteradoEm; 


"ia 


* @var \DateTime|null 
* @ORM\Column(name="dt_deletado_em", 
type="datetime", nullable=true, options={"comment"="Data 
de exclusao"}) 
J 
private $deletadoEm; 


pur 
* TipoUsuario constructor. 
* @param array $data 
“7 
public function | construct(array $data = []) 
{ 
$this->criadoEm = new \DateTime('now'); 
(new ClassMethods())->hydrate($data, $this); 


fee 

* @return int 

*7 
public function getId(): int 
{ 


return $this->id; 


pe 
* @return string 
"p 
public function getTipo(): string 


{ 


return $this->tipo; 


ea 
* @param string $tipo 
* @return TipoUsuario 


-F 


public function setTipo(string $tipo): 


{ 
$this->tipo = $tipo; 
return $this; 


FER 
* @return bool 
"y 
public function isAtivo(): bool 


{ 


return $this->ativo; 


pa 
* @param bool $ativo 
* @return TipoUsuario 
a À 


public function setAtivo(bool $ativo): 


{ 
$this->ativo = $ativo; 
return $this; 


pue 
* @return \DateTime 
me 


TipoUsuario 


TipoUsuario 


public function getCriadoEm(): \DateTime 


{ 


return $this->criadoEm; 


Lee 
* (return TipoUsuario 
"7 


public function setCriadoEm(): TipoUsuario 


$this->criadoEm = new \DateTime('now'); 
return $this; 


q 

* @return \DateTime|null 

"A 
public function getAlteradoEm(): ?\DateTime 
{ 


return $this->alteradoEm; 


jee 
* @return TipoUsuario 
*/ 
public function setAlteradoEm(): TipoUsuario 
{ 
$this->alteradoEm = new \DateTime('now'); 
return $this; 


pee 

* (return \DateTime|null 

"y 
public function getDeletadoEm(): ?\DateTime 
{ 


return $this->deletadoEm; 


yee 
* @return TipoUsuario 
é À 
public function setDeletadoEm(): TipoUsuario 
{ 
$this->deletadoEm = new \DateTime('now'); 
return $this; 


E” * 
* @return array 
"y 
public function toArray(): array 
{ 
return (new ClassMethods())->extract($this); 
} 
} 
Conclusão 


Chegamos ao final do capítulo, vimos aqui como melhorar 
nossa entidade TbTipoUsuario que foi gerada pelo 
Doctrine, alterando o nome, o nome das propriedades, 
definindo namespace, criando métodos, ativando o modo 
estrito do PHP 7 e definindo o repositório dela. 
Conhecemos também o componente Zend Hydrator que 
agiliza nosso desenvolvimento atribuindo os valores para 
as propriedades da classe de forma automática, através 
de seus métodos setters . Conseguimos também obter o 
conjunto de valores das propriedades da classe em forma 
de array. 


No próximo capítulo vamos melhorar a entidade 
TbUsuario igual fizemos com a nossa entidade 
TbTipoUsuario . Então, siga em frente e vamos nessa! 


CAPÍTULO 8 
Melhorando a entidade TbUsuario 


Assim como fizemos com a entidade TipoUsuario , 
também faremos com a  Tbusuario , porém, como as 
alterações são do mesmo tipo, não será detalhado tão na 
integra como fizemos na anterior. No fim desta seção 
você poderá ver o código completo da entidade. 


Alterando o nome da entidade 


Primeiramente, vamos alterar o nome da entidade. Edite-o 
com o nome usuario e, em seguida, abra a entidade e 
altere também o nome da classe para Usuario . 


Definindo o modo estrito do PHP 7 


Agora vamos habilitar o modo estrito do PHP 7 inserindo o 
código a seguir logo após a tag de abertura do PHP: 


declare(strict types=1); 
Definindo o namespace 


Nosso próximo passo é definir o namespace da entidade. 
Como dito anteriormente, as entidades não possuem um 
namespace definido após sua geração pelo Doctrine. 
Coloque o código a seguir no começo da sua entidade, 
antes do nome da classe e até mesmo antes da 
declaração use : 


namespace App\Entity; 


Alterando o nome das propriedades 


Assim como fizemos com a nossa entidade TipoUsuario , 
também temos que alterar o nome das propriedades da 
entidade para torná-las mais legível e de mais fácil 
compreensão. Altere o nome das propriedades da sua 
entidade conforme o código a seguir: 


per 
* @var int 
* @ORM\Column(name="id", type="integer", 
nullable=false) 
* @ORM\Id 
* @ORM\GeneratedValue(strategy="IDENTITY" ) 
nad 
private $id; 


per 
* @var string 
* (QORMNColumn(name="nm nome completo”, 
type="string", length=150, nullable=false, options= 
{"comment"="Nome completo do usuário") 
wi J 
private $nomeCompleto; 


JER 
* @var string 


* 


* (QORMNColumn(name="cd cpf", type="string", 
length=11, nullable=false, options={"comment"="CPF"}) 
"7 
private $cpf; 


Je. 
* (var \DateTime 


* 


* @ORM\Column(name="dt_nascimento", type="date", 
nullable=false, options={"comment"="Data de nascimento"}) 
-y 
private $dataNascimento; 


e. 
* @var string 
* @ORM\Column(name="nm_email", type="string", 
length=100, nullable=false) 
"E 
private $email; 


per 
* (Ovar string 
* @ORM\Column(name="nm_senha", type="string", 
length=255, nullable=false, options={"comment"="Senha"}) 
"> 
private $senha; 


fee 
* @var bool 
* 
* @ORM\Column(name="St_ativo", type="boolean", 
nullable=false, options={"default"="1", "comment"="Esta 
ativo? 


O - Nao 
i - SH) 
"e 


private $ativo = true; 


pee 
* @var \DateTime 


* 


* @ORM\Column(name="dt_criado_em", type="datetime", 


nullable=false, options= 
("default"="CURRENT_TIMESTAMP","comment"="Data de criação 
do registro"}) 
-y 
private $criadoEm = 'CURRENT_TIMESTAMP! ; 


ia 
* @var \DateTime|null 
* @ORM\Column(name="dt_alterado_em", 
type="datetime", nullable=true, options={"comment"="Data 
de alteracao do registro"}) 
"y 
private $alteradoEm; 


pea 
* @var \DateTime|null 
* @ORM\Column(name="dt_deletado_em", 
type="datetime", nullable=true, options={"comment"="Data 
de exclusao do registro"}) 
al J 
private $deletadoEm; 


ea 
* @var TipoUsuario 
* 
* @ORM\ManyToOne(targetEntity="TipoUsuario" ) 
* @ORM\JoinColumns({ 
> @ORM\ JoinColumn(name="tipo usuario id”, 
referencedColumnName="id" ) 
* 3) 
a J 
private $tipoUsuario; 


Um ponto a ser considerado é a propriedade 
$tipoUsuario , que possui relacionamento com a entidade 


TipoUsuario . Perceba as anotações do Doctrine acima da 
propriedade informando que ela possui um 
relacionamento. 


Definindo o repositório na entidade 


Escreva o código a seguir em sua entidade, substituindo a 
annotation (anotação) @orM\Entity que está localizada 
acima do nome da classe: 


@ORM\Entity(repositoryClass="App\Repository\UsuarioReposi 
tory") 


Definindo os métodos da entidade usuario 


Nosso último passo para a nossa entidade é definirmos os 
métodos. Escreva o código a seguir em sua entidade: 


per 
* Usuario constructor. 
* @param array $data 
us 
public function _ construct(array $data = []) 
{ 
$this->criadoEm = new \DateTime('now'); 
(new ClassMethods())->hydrate($data, $this); 


| ne 

* @return int 

my 
public function getId(): int 
{ 


return $this->1d; 


| a 
* @return string 
=f 
public function getNomeCompleto(): string 


{ 


return $this->nomeCompleto; 


fem 
* @param string $nomeCompleto 
* @return Usuario 
“e 
public function setNomeCompleto(string $nomeCompleto): 
Usuario 
{ 
$this->nomeCompleto = $nomeCompleto; 
return $this; 


JER 

* @return string 

ia 
public function getCpf(): string 
{ 


return $this->cpf; 


per 
* @param string $cpf 
* @return Usuario 
“e 
public function setCpf(string $cpf): Usuario 
{ 
$this->cpf = $cpf; 
return $this; 


pa 
* @return \DateTime 


=f 
public function getDataNascimento(): \DateTime 
{ 
return $this->dataNascimento; 
} 
JER 


* @param \DateTime $dataNascimento 
* @return Usuario 
é 


public function setDataNascimento(\DateTime 


$dataNascimento): Usuario 


{ 


$this->dataNascimento = $dataNascimento; 


return $this; 


JER 
* @return string 
“T 
public function getEmail(): string 


{ 


return $this->email; 


per 
* @param string $email 
* @return Usuario 
=f 


public function setEmail(string $email): 


{ 
$this->email = $email; 
return $this; 


Usuario 


pu 
* (return string 


=f 
public function getSenha(): string 
{ 
return $this->senha; 
} 
JER 


* @param string $senha 
* @return Usuario 
ii 
public function setSenha(string $senha): Usuario 
{ 
$this->senha = $this->encriptarSenha($senha); 
return $this; 


JER 
* @return bool 
eS 
public function isAtivo(): bool 


{ 


return $this->ativo; 


pa 
* @param bool $ativo 
* @return Usuario 
a? 
public function setAtivo(bool $ativo): Usuario 
{ 
$this->ativo = $ativo; 
return $this; 


"sia 


* (return \DateTime 
-7 
public function getCriadoEm(): \DateTime 


{ 


return $this->criadoEm; 


yee 
* @return Usuario 
a 
public function setCriadoEm(): Usuario 
{ 
$this->criadoEm = new \DateTime('now'); 
return $this; 


PA 

* @return \DateTime|null 

a 
public function getAlteradoEm(): ?\DateTime 
{ 


return $this->alteradoEm; 


JER 
* @return Usuario 
a 
public function setAlteradoEm(): Usuario 
{ 
$this->alteradoEm = new \DateTime('now'); 
return $this; 


per 
* @return \DateTime|null 
ai 
public function getDeletadoEm(): ?\DateTime 


return $this->deletadoEm; 


gee 
* @return Usuario 
E 
public function setDeletadoEm(): Usuario 
{ 
$this->deletadoEm = new \DateTime('now'); 
return $this; 


fee 
* @return TipoUsuario 
"T 
public function getTipoUsuario(): TipoUsuario 


{ 


return $this->tipoUsuario; 


pa 
* (param TipoUsuario $tipoUsuario 
* @return Usuario 
“a 
public function setTipoUsuario(?TipoUsuario 
$tipoUsuario): Usuario 
{ 
$this->tipoUsuario = $tipoUsuario; 
return $this; 


É at 
* @return array 
ee 
public function toArray(): array 


{ 


return (new ClassMethods())->extract($this); 


/** 
* @param string $senha 
* @return string 
é 

public function encriptarSenha(string $senha): string 


{ 


return md5($senha); 


} 


A novidade em nossa entidade é o metodo 

encriptarSenha que, como o proprio nome já diz, é 
responsável por realizar a encriptação da senha do 
usuario. Aqui vamos utilizar o md5 do PHP porque é 
simples e atende bem o que deve ser mostrado, mas você 
pode tentar implementar outro algoritmo de encriptação, 
como O sha256 , por exemplo. 


Chegamos ao fim das alterações de mais uma entidade, e 
como o código completo dela é grande, você poderá 
conferi-lo no GitHub: https://github.com/jhones/livro-zend- 
expressive/blob/master/src/App/src/Entity/Usuario.php/. 


Conclusão 


Neste capítulo, vimos como melhorar nossa entidade 
Tbusuario , que foi gerada pelo Doctrine alterando o 
nome, o nome das propriedades, definindo namespace, 
criando métodos, ativando o modo estrito do PHP 7 e 
definindo o repositório dela. 


No próximo capítulo, vamos melhorar a entidade 
TbMensagem COMO fizemos com as TbTipoUsuario € 


TbUsuario . Então, siga em frente e vamos nessa! 


CAPÍTULO 9 
Melhorando a entidade TbMensagem 


Por fim, vamos realizar as alterações em nossa ultima 
entidade. Vamos em frente! 


Alterando o nome da entidade 


Primeiramente, vamos alterar o nome da entidade. Edite-o 
com o nome de Mensagem e, em seguida, abra a entidade 
e altere também o nome da classe para Mensagem . 


Definindo o modo estrito do PHP 7 


Vamos habilitar o modo estrito do PHP 7 inserindo o 
código a seguir logo após a tag de abertura do PHP: 


declare(strict types=1); 
Definindo o namespace 


Para definir o namespace, escreva o código a seguir no 
começo da sua entidade, antes do nome da classe e 
antes da declaração use: 


namespace App\Entity; 
Alterando o nome das propriedades 


Assim como fizemos com as entidades anteriores, 
também faremos com essa. Altere o nome das 
propriedades da sua entidade conforme o código a seguir: 


F (quado 


* Ovar int 
* @ORM\Column(name="id", type="integer", nullable=false) 
* @ORM\Id 
* @ORM\GeneratedValue(strategy="IDENTITY" ) 
*y 
private $id; 


/** 

* @var string 

* 

* @ORM\Column(name="ds_mensagem", type="text", 
length=65535, nullable=false, options= 
("comment"="Descricáo da mensagem"}) 

"p 
private $mensagem; 


fee 

* @var string|null 

* @ORM\Column(name="ds_resposta", type="text", 
length=65535, nullable=true) 

"7 
private $resposta; 


r int 
* @var \DateTime 


* 


* @ORM\Column(name="dt_mensagem", type="datetime", 
nullable=false, options={"comment"="Data da mensagem"}) 
as 
private $dataMensagem; 


per 
* @var bool 


* 


* @ORM\Column(name="St_ativo", type="boolean", 


nullable=false, options=("default"="1","comment"="Está 
ativo? 
O - Não 
1 - Sim"}) 
“> 
private $ativo = true; 


fee 
* @var \DateTime 
* @ORM\Column(name="dt_criado_em", type="datetime", 
nullable=false, options={"default"="CURRENT_TIMESTAMP" } ) 
"e 
private $criadoEm = ' CURRENT TIMESTAMP!; 


gua 

* (Ovar \DateTime|null 

* (QORMNColumn(name="dt alterado em", type="datetime", 
nullable=true) 

E 
private $alteradoEm; 


per 

* (Ovar \DateTime|null 

* (OORMNColumn(name="dt deletado em", type="datetime", 
nullable=true) 

"7 
private $deletadoEm; 


É aaus 
* @var Usuario 
* @ORM\ManyToOne(targetEntity="Usuario" ) 
* @ORM\JoinColumns({ 
né QORMNJoinColumn(name="usuario id”, 


referencedColumnName="id") 
” +) 

"F 

private $usuario; 


Perceba que nossa entidade mensagem também possui um 
relacionamento, que se dá pela propriedade $usuario , 
que se relaciona com a entidade usuario. 


Definindo o repositório na entidade 


Escreva o código a seguir em sua entidade, substituindo a 
annotation (anotação) @oRrM\Entity que está localizada 
acima do nome da classe: 


@ORM\Entity(repositoryClass="App\Repository\MensagemRepos 
itory") 


Definindo os métodos da entidade Mensagem 


Nosso ultimo passo para a nossa entidade é definirmos os 
métodos. Escreva o código a seguir em sua entidade: 


pur 
* Usuario constructor. 
* @param array $data 
“a 
public function __construct(array $data = []) 
{ 
$this->criadoEm = new \DateTime('now'); 
(new ClassMethods())->hydrate($data, $this); 


paa 
* @return int 
"y 
public function getId(): int 


return $this->id; 


É incita 
* @return string 
E 
public function getMensagem(): string 


{ 


return $this->mensagem; 


ses 
* @param string $mensagem 
* (return Mensagem 
“7 
public function setMensagem(string $mensagem): Mensagem 
{ 
$this->mensagem = $mensagem; 
return $this; 


Í 
pee 

* @return null|string 

"p 
public function getResposta(): ?string 
{ 

return $this->resposta; 

3 
paa 


* @param null|string Sresposta 
* (return Mensagem 
=f 
public function setResposta(?string $resposta): Mensagem 


{ 


$this->resposta = $resposta; 


return $this; 


y 
pr 

* (return \DateTime 

a 
public function getDataMensagem( ): 
{ 

return $this->dataMensagem; 

3 
pa 


* @param \DateTime $dataMensagem 
* @return Mensagem 


\DateTime 


Mensagem 


a 
public function setDataMensagem(): 
{ 
$this->dataMensagem = new \DateTime('now'); 
return $this; 
3 
jee 
* @return bool 
"y 


public function isAtivo(): bool 


{ 


return $this->ativo; 


fun 
* @param bool $ativo 
* @return Mensagem 
ki 


public function setAtivo(bool $ativo): Mensagem 


{ 
$this->ativo = $ativo; 
return $this; 


pe 
* (return \DateTime 
y 
public function getCriadoEm(): \DateTime 


{ 


return $this->criadoEm; 


/** 
* @return Mensagem 
a 
public function setCriadoEm(): Mensagem 
{ 
$this->criadoEm = new \DateTime('now'); 
return $this; 


per 

* @return \DateTime|null 

*/ 
public function getAlteradoEm(): ?\DateTime 
{ 


return $this->alteradoEm; 


Pee 
* @return Mensagem 
iy 
public function setAlteradoEm(): Mensagem 


{ 


$this->alteradoEm = new \DateTime('now' ); 
return $this; 


l pisu 


* @return \DateTime|null 

-7 
public function getDeletadoEm(): ?\DateTime 
{ 


return $this->deletadoEm; 


ft? 
* @return Mensagem 
hj 
public function setDeletadoEm(): Mensagem 


{ 


$this->deletadoEm = new \DateTime('now'); 


return $this; 


É an 
* (return Usuario 
"e 
public function getUsuario(): Usuario 


{ 


return $this->usuario; 


fen 
* @param Usuario $usuario 
* @return Mensagem 


ef 
public function setUsuario(Usuario $usuario): 
{ 
$this->usuario = $usuario; 
return $this; 
} 
per 


* @return array 
*/ 


Mensagem 


public function toArray(): array 


{ 


return (new ClassMethods())->extract($this); 


} 


Após definirmos os métodos, perceba que nao houve 
grandes diferenças se comparado com as outras 
entidades que criamos. Utilizamos o componente Zend 
Hydrator para hidratar/popular e também para extrair os 
dados. Como estamos utilizando interface fluente em 
nossa entidade, todos os métodos setters possuem 
retorno do tipo mensagem , assim podemos utilizar outros 
métodos da classe sem a necessidade de chamar 
novamente a variável do objeto, por exemplo: 


$object->setResposta( 'Resposta'); 
$object->setAlteradoEm(); 


Através da interface fluente, podemos chamar os métodos 
da classe se houver necessidade de chamar novamente a 
variável do objeto, por exemplo: 


$0object->setResposta(' Resposta!) 
->setAlteradoEm( ) 
->setAtivo(true); 


Com isso, finalmente finalizamos as alterações em nossas 
entidades. Como o código completo dessa classe é 
grande, você poderá vê-lo no GitHub: 
https://github.com/jhones/livro-zend- 

expressive/blob/master/src/App/src/Entity/Mensagem.php/ 


Conclusao 


Chegamos ao final do nosso ultimo capítulo da série de 
melhoria das entidades que foram geradas pelo Doctrine. 
Durante essa série de três capítulos você conheceu o 
Zend Hydrator e como esse componente do Zend 
Framework pode nos ajudar. Além disso, criamos diversos 
métodos, alteramos o nome das entidades e das 
propriedades de cada uma e muito mais. 


No próximo capítulo vamos criar os repositórios de cada 
classe e definir alguns métodos que vamos utilizar em 
nosso projeto de comunicação entre usuários. Então, siga 
em frente e vamos nessa! 


CarítuLo 10 
Criando repositórios e estendendo a 
classe EntityRepository 


Agora que já definimos e melhoramos as nossas 
entidades, devemos criar os repositórios. Como você 
pôde notar, cada entidade possui o seu repositório, 
lembra? Nós definimos cada repositório, mas ainda não 
OS criamos. 


Neste capítulo, vamos criar os repositórios contendo 
alguns métodos que utilizaremos futuramente em nossos 
serviços. 


10.1 Criando O repositório 
TipoUsuarioRepository 


O repositório é como um complemento da entidade e é 
utilizado para realizar as consultas ao banco de dados. É 
onde ficam os métodos que integram as regras de 
negócio da nossa aplicação. O repositório separa da 
entidade todas as consultas realizadas diretamente no 
banco de dados, deixando a aplicação mais organizada. 
Além disso, podemos utilizar o objeto do repositório em 
outras partes da aplicação. 


Antes de criarmos nosso repositório, devemos criar nosso 
diretório Repository , que é onde ficarão todas as nossas 
classes de repositório. Vamos criá-lo no caminho 
src/App/src/ , conforme mostra a imagem a seguir: 
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Figura 10.1: Criando o diretório Repository 


Dentro deste diretório, vamos criar o repositório 
propriamente dito. Crie uma classe com o nome 
TipoUsuarioRepository conforme mostra a imagem a 


seguir: 
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Figura 10.2: Criando o repositório TipoUsuarioRepository 


Nosso próximo passo é escrevermos código em nossa 
classe. Para facilitar o entendimento, primeiro vamos ver o 
código completo da nossa classe e, em seguida, vou 
explicar o que foi feito na classe e qual a finalidade do que 
estamos fazendo. Veja o código completo da classe 
TipoUsuarioRepository a seguir: 


<?php 


declare(strict types=1); 


namespace App\Repository; 
use Doctrine\ORM\EntityRepository; 


ga 

* Class TipoUsuarioRepository 

* (package App\Repository 

eS 
class TipoUsuarioRepository extends EntityRepository 
implements RepositoryInterface 


{ 
pa 
* Qreturn array|null 
"y 
public function getAll(): ?array 
{ 
$data = $this->findAll(); 
$dataArray = []; 
foreach ($data as $object) { 
$dataArray[] = $object->toArray(); 
} 
return $dataArray; 
} 
pe 


* @param int $id 

* @return null|object 

-y 
public function getOne(int $id) 
{ 

return $this->findOneBy(['id' => $id])- 
>toArray(); 

} 


pe 


* Qreturn array |null 


at 
public function getAllWithDQL(): ?array 
{ 
$dql = <<<DQL 
SELECT 
tid; 
Ee taui, 
t.ativo 
FROM App\Entity\TipoUsuario t 
ORDER BY t.tipo ASC 
DQL; 
$query = $this->getEntityManager ( ) - 
>createQuery($dql); 
return $query->getResult(); 
3 
jee 


* @param int $id 
* @return array|null 
*/ 


public function getOnewithDQL(int $id): 


{ 
$dql = <<<DQL 
SELECT 
ee eo P 
Ee LO, 
t.ativo 
FROM App\Entity\TipoUsuario t 
WHERE 
t.id = $id 
DQL; 


$query = $this->getEntityManager ()- 
>createQuery($dql); 
return $query->getResult(); 


?array 


} 


A lógica que você pode ver na classe 
TipoUsuarioRepository será basicamente a mesma nas 
demais classes de repositórios que criaremos mais 
adiante. Para todas, vamos: 


e Ativar o modo estrito do PHP 7; 

Estender a classe EntityRepository do Doctrine; 
Implementar a interface RepositoryInterface que foi 
criada; 

Entender os métodos implementados. 


A ativação do modo estrito do PHP 7 não será mais 
explicada daqui para a frente, já que no capítulo anterior 
você já aprendeu bastante como utilizá-lo, e por todo o 
projeto será da mesma forma. 


Estendemos a classe EntityRepository em nosso 
repositório para informarmos que a nossa classe deve 
herdar as características de um repositório do Doctrine, ou 
seja, por meio dessa herança o Doctrine vai interpretar 
que a nossa classe TipoUsuarioRepository é, de fato, um 
repositório válido para o Doctrine, além de poder utilizar 
diversos métodos já criados na classe EntityRepository . 


Logo após estendermos a classe EntityRepository nós 
estamos implementando a interface RepositoryInterface , 
que foi criada para que todos os nossos repositórios 
tenham um padrão em comum que será obrigatório para 
os nossos exemplos. O código completo da nossa 
interface RepositoryInterface pode ser visto a seguir: 


<?php 


declare(strict types=1); 
namespace App\Repository; 


per 
* Interface RepositoryInterface 
* @package App\Repository 
as 
interface RepositoryInterface 
{ 
/** 
* (return array |null 
"y 
public function getAll(): ?array; 


per 
* @param int $id 
* @return mixed 
"y 

public function getOne(int $id); 


pee 
* @return array|null 
"y 
public function getAllWithDQL(): ?array; 


pur 
* @param int $id 
* Qreturn array|null 
id À 
public function getOnewithDQL(int $id): ?array; 
3 


y 


Vamos entender qual é a responsabilidade de 
método dessa interface: 


cada 


e getAll(): ?array - É responsável por retornar todos 
os dados de uma determinada entidade, incluindo 
todos os campos que nela existirem. É um método 
utilizado para demonstrar um pouco da 
funcionalidade e as maneiras que temos para 
executar uma mesma ação. Perceba que esse 
método retorna um array ou um valor nulo. O código 
?array Informa exatamente isso, ou seja, ou retorna 
um array ou retorna um valor nulo. 


e getone(int $id) - Possui como responsabilidade 

retornar apenas um registro do banco, ou seja, esse 
método não retorna uma coleção de dados como o 
método getAll . Observe que o parámetro int id é 
obrigatório e por meio dele vamos consultar apenas 
um registro no banco que possuir o id informado. 
Um ponto importante a ser observado é que nesse 
método não foi definido o tipo de retorno, isso 
porque o Doctrine nos enviará um retorno do tipo 
null OU object . O retorno do tipo object ainda 
não é suportado pelo PHP 7, e por esse motivo nao 
foi definido qual sera o retorno do metodo. Nesse 
caso estamos confiando apenas no que o Doctrine 
nos enviar. 


e  getAllwithDQL(): ?array - O funcionamento desse 
método é semelhante ao do método getall, a única 
diferença é que no método getallwithDoL utilizamos 
a linguagem DQL do Doctrine, que nada mais é o 
próprio SQL adaptado para funcionamento com o 
Doctrine. 


e getOneWithDQL(int $id): ?array - O funcionamento 
desse método é semelhante ao do getone , tendo 


duas diferenças: a primeira, o tipo de retorno 
esperado pelo método; a outra diferença é que será 
utilizada a linguagem DQL. Tanto o método 
getonewithDoL quanto O getAllwithpga. foram 
criados para demonstrar como fazer consultas 
utilizando a linguagem DQL. 


Após temos aprendido qual a finalidade de cada método 
da interface RepositoryInterface vamos analisar cada 
método implementado em nossa classe 
TipoUsuarioRepository . 


getall() - É um método bem simples, que realiza 
uma consulta buscando todos os dados contidos no 
banco de dados. Perceba que estamos utilizando o 
método $this->findAll() do Doctrine, obtido por 
meio da herança que fizemos da classe 

EntityRepository , e estamos armazenando o 
resultado na variável $data para que possamos 
utilizar no foreach . Dentro do foreach , temos a 
variável $object que estamos utilizando, e estamos 
chamando o método toarray() que está contido 
dentro da entidade Tipousuario . Estamos 
armazenando os dados na variável $dataArray para 
que possamos retornar os dados corretamente 
conforme o tipo de retorno esperado pelo método. 
Como dito, esse método busca todos os registros do 
banco de dados incluindo todos os campos. Em 
aplicações pequenas que não possuem tantos 
dados, não há problemas em utilizá-lo, porém é 
recomendado evitar seu uso, pois nem sempre você 
quer todos os campos de uma determinada entidade 
e isso também torna a consulta mais lenta. 


getOne(int $id) - Também é um metodo bastante 
simples e possui apenas uma linha. Esse método 
realiza a busca de apenas um registro, e isso é feito 
por meio do parâmetro id , que é do tipo inteiro, 
caso contrário um erro será lançado. Perceba que 
estamos utilizando o método $this->findOneBy(['id' 
=> $id]) também disponibilizado por meio da 
herança com a classe EntityRepository . Estamos 
informando um array como parâmetro, passando 
como chave o nome id, que é o nome da 
propriedade em nossa entidade  Tipousuario , e 
estamos passando como valor o parâmetro $id 
Podemos passar qualquer campo existente na 
entidade como critério de busca no método 
findoneBy , lembrando que o tipo de parámetro 
desse método é array. Por fim temos o método 
toArray que está sendo chamado logo após o 
método findoneBy . O método toarray está contido 
dentro da entidade Tipousuario , como o método 
findoneBy retorna o objeto da entidade, então temos 
acesso a esse método. 


getallwithDoL() - Esse método tem o mesmo 
objetivo do método getall , porém fizemos uma 
modificação. Dessa vez, perceba que existe sintaxe 
SQL no método, mas na verdade é o DQL. É bem 
semelhante ao SQL convencional, mas uma das 
diferenças que você pode notar é que, após O FROM, 
em vez de usarmos o nome da tabela como 
costumamos fazer, estamos utilizando o nome da 
entidade que criamos com seu namespace 
completo. Perceba que, dessa vez, estamos 
buscando apenas algumas colunas ( id, tipo e 


ativo ) que, no nosso caso, são os nomes das 
propriedades na entidade Tipousuario . Para realizar 
a consulta, estamos utilizando a sequência de 
métodos do Doctrine $this->getEntityManager()- 
>createQuery($dq1) , que realiza a consulta do nosso 
código DQL e armazena um objeto query em nossa 
variável. Logo em seguida, chamamos o método 
$query->getResult() que retornará o resultado da 
nossa consulta. Perceba que o método getResult 
pertence ao objeto Query. 


e getOnewWithDQL(int $id) - Por fim esse método 
também possui o mesmo funcionamento que o 
método  getone , a diferença é que estamos 
utilizando o DQL. Perceba que nao muda muita 
coisa do método getallwithDboL , Mas aqui o método 
getonewithDoL recebe um parámetro que é o id do 
tipo inteiro e adicionamos a cláusula wHERE para 
informar que queremos buscar apenas pelo id. O 
modo de realizar a consulta e obter o resultado é 
exatamente o mesmo do método getAllwithDQL . 


Com isso, finalizamos a criação do nosso repositório 

TipousuarioRepository . Criar um repositório com o 
Doctrine não é uma tarefa complicada, já que ele 
disponibiliza tudo o que precisamos. 


Se você gostaria de conhecer mais sobre o DQL e 
ver mais exemplos, basta você acessar o link 
https://www.doctrine-project.org/projects/doctrine- 
orm/en/2.6/reference/dql-doctrine-query- 


language.html/. O Doctrine possui uma excelente 
documentacáo, vale a pena dar uma conferida na 
documentação completa no link https://www.doctrine- 
project.org/projects/doctrine-orm/en/2.6/index.html/, 
navegue e conheça melhor esse incrível ORM. 





10.2 Criando o repositório UsuarioRepository 


Agora que já criamos o repositório TipoUsuarioRepository , 
vamos criar o repositório usuarioRepository . Crie uma 
classe com o nome usuarioRepository conforme mostra a 
imagem a seguir: 


Y Em livro-zend-expressive 


Mm 


Repositoryint 





Figura 10.3: Criando o repositório UsuarioRepository 


Nosso próximo passo é escrever o código em nossa 
classe. Vamos primeiro ver o código completo da nossa 
classe, mas daqui em diante, só seráo explicadas as 
alterações em relação ao anterior, pois o funcionamento 
será basicamente o mesmo. Vamos herdar a classe 

EntityRepository e implementar a interface 
RepositoryInterface e assim será com qualquer outro 
repositório que criarmos. Veja o código completo da 


classe UsuarioRepository a seguir: 
<?php 
declare(strict types=1); 
namespace App\Repository; 
use Doctrine\ORM\EntityRepository; 
r idaho 

* Class UsuarioRepository 

* @package App\Repository 

=F 


class UsuarioRepository extends EntityRepository 
implements RepositoryInterface 


{ 
Ja 
* @return array|null 
"y 
public function getAll(): ?array 
{ 


$data = $this->findAll(); 
$dataArray = []; 


foreach ($data as $object) { 
$dataArray[] = Sobject->toArray(); 


return $dataArray; 


jee 
* @param int $id 
* @return mixed|null|object 
-y 

public function getOne(int $id) 


return $this->findOneBy(['id' => $id])- 
>toArray(); 
} 


/** 
* @return array |null 
af 
public function getAllWithDQL(): ?array 
{ 
$dql = <<<DQL 
SELECT 
o; 
.nomeCompleto, 
«ativo, 
«Cpf, 
.dataNascimento, 
email, 
«ativo, 
«ld as tipoUsuario 
FROM App\Entity\Usuario u 
INNER JOIN u.tipoUsuario t 
ORDER BY u.nomeCompleto ASC 


+ E EA GG G E 


DQL; 


$query = $this->getEntityManager ( ) - 
>createQuery($dql); 
return $query->getResult(); 


jer 
* @param int $id 
* @return array|null 
of É 

public function getOnewithDQL(int $id): ?array 


{ 
$dql = <<<DQL 


SELECT 

Utd; 
.nomeCompleto, 
«ativo, 
CAT, 
.dataNascimento, 
.email, 
«ativo, 
.id as tipoUsuario 
FROM App\Entity\USuario u 
INNER JOIN u.tipoUsuario t 
WHERE 

u.id = $id 


rr EC & E 


DQL, 


$query = $this->getEntityManager ( ) - 
>createQuery($dql); 
return $query->getResult(); 


Como você pode notar, o código é bem parecido com o da 
classe TipoUsuarioRepository e há diferenças em apenas 
dois métodos, sendo eles o getAllwithDQL() e 
getOnewithDQL(int $id) . A principal diferença é que em 
ambos os métodos você pode notar a utilização do INNER 
JOIN no formato DQL. O Doctrine vai identificar o 
relacionamento por meio do campo tipoUsuario , que 
possui as annotations (anotações) indicando com qual 
entidade e coluna do banco de dados a propriedade se 
relaciona. 


Não é do escopo deste livro focar no Doctrine, mas 
sim passar o necessário que vamos utilizar em nosso 
projeto. Caso tenha interesse em aprender mais 
sobre relacionamentos com o Doctrine, você pode 


acessar o link da documentação oficial, que contém 
inúmeros exemplos. Confira em https://www.doctrine- 
project.org/projects/doctrine- 
orm/en/2.6/reference/association-mapping.html. 





10.3 Criando o repositório MensagemRepository 


Por fim, vamos criar o nosso último repositório, que será 
responsável pelas mensagens que um determinado 
usuário poderá trocar com outro. Primeiramente, vamos 
criar nossa classe conforme mostra a imagem a seguir: 
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Figura 10.4: Criando o repositório MensagemRepository 


Com a classe MensagemRepository criada, vamos ver O 
código completo dela a seguir: 


<?php 
declare(strict types=1); 


namespace App\Repository; 


use Doctrine\ORM\EntityRepository; 


per 

* Class MensagemRepository 

* @package App\Repository 

a É 
Class MensagemRepository extends EntityRepository 
implements RepositoryInterface 


{ 
ue 
* (return array|null 
Cf 
public function getAll(): ?array 
{ 


$data = $this->findAll(); 
$dataArray = []; 


foreach ($data as $object) { 
$dataArray[] = Sobject->toArray(); 


return $dataArray; 


Jee 
* @param int $id 
* @return mixed|null|object 
of É 
public function getOne(int $id) 
{ 
return $this->findOneBy(['id' => $id])- 
>toArray(); 
} 


pa 
* Qreturn array|null 
“7 


public function getAllWithDQL(): ?array 


{ 

$dql = <<<DQL 

SELECT 

m.id, 

.mensagem, 
.resposta, 
.dataMensagem, 
«ativo, 
«ld as usuario 
FROM App\Entity\Mensagem m 
INNER JOIN m.usuario u 
ORDER BY m. dataMensagem DESC 


oz s 


DQL, 


$query = $this->getEntityManager ( ) - 


>createQuery($dql); 
return $query->getResult(); 


e 
* (param int $id 
* @return array|null 
al É 


public function getOnewithDQL(int $id): 


{ 
$dql = <<<DQL 

SELECT 
Ms 
. mensagem, 
. resposta, 
.dataMensagem, 
«ativo, 
«ld as usuario 
FROM App\Entity\Mensagem m 
INNER JOIN m.usuario u 
WHERE 


“Soo 


?array 


m.id = $id 
DQL, 


$query = $this->getEntityManager ( ) - 
>createQuery($dql); 
return $query->getResult(); 


jer 
* @param int $userId 
* @return array|null 
W 
public function getMessagesFromUser (int $userId): ? 
array 
{ 
$dql = <<<DQL 
SELECT 
es 
.mensagem, 
. resposta, 
.dataMensagem, 
«ativo, 
«ld as usuario 
FROM App\Entity\Mensagem m 
INNER JOIN m.uSuario u 
WHERE 
u.id = $userld 


© S S Sla 


DQL; 


$query = $this->getEntityManager()- 
>createQuery($dql); 
return $query->getResult(); 


} 


Ao analisar o código, você pode perceber que nao ha 
grandes mudanças nos métodos implementados pela 


interface RepositoryInterface . À novidade nessa classe é 
o método getMessagesFromUser , que possui a 
responsabilidade de recuperar todas as mensagens de 
um determinado usuario através do id de usuário 
passado como parâmetro do método. Os demais códigos 
não sofreram alterações que requerem explicações 
aprofundadas. As alterações foram apenas nos campos a 
serem retornados, no relacionamento e no nome da 
entidade na qual será realizada a consulta. Com isso, 
chegamos ao final de mais um capítulo. 


Conclusão 


Vimos como criar repositórios utilizando o Doctrine e a 
linguagem DQL, que é o SQL adaptado para o Doctrine. 
Além disso, criamos uma interface que provê métodos 
comuns entre todas as classes de repositórios. Em nosso 
próximo capítulo, vamos criar e registrar os serviços que 
serão responsáveis por fazer a mediação entre o 
repositório e o middleware. Vale a pena ressaltar que, 
devido à flexibilidade do Zend Expressive, você pode 
optar por trabalhar da maneira que melhor convém ao 
projeto, ou como você já esteja habituado. Então, siga em 
frente e vamos nessa. 


CapPiTULO 11 
Criando e registrando serviços 


Agora que já temos definidos os nossos repositórios, está 
na hora de criarmos e registrarmos os nossos serviços 
que serão responsáveis por realizar as operações de 
CRUD (Create, Read, Update, Delete) e outros tipos de 
operações. 


O que É CRUD? 


CRUD ou Create Read Update Delete, significa: 


Create - Cria um determinado registro; não importa 
qual tipo, o registro deverá ser criado de acordo com 
a necessidade da sua aplicação. 


Read - Leitura/Listagem de dados; obtém os dados 
armazenados no banco de dados para que possam 
ser tratados e/ou apresentados para o usuário. 


Update - Atualiza um determinado registro que já foi 
inserido anteriormente no banco de dados. 


Delete -  Deleta/Exclui/Remove/Apaga registros 
armazenados no banco de dados. 





Os servicos seráo responsáveis por disponibilizar para 
toda a aplicação meios de poder realizar as operações de 
CRUD, bem como outros tipos de operações que o 
servico possa ter futuramente. Cada servico que criarmos 


em nosso projeto realizará as operações de CRUD de 
acordo com cada repositório que criamos no capítulo 
anterior. Mas não basta criarmos os serviços em um 
diretório e achar que ele já poderá ser utilizado pelo resto 
da aplicação; para que isso seja possível, precisamos 
registrar cada serviço em nosso arquivo de configuração. 
Mais adiante neste capítulo veremos como fazer isso. 


Nas próximas seções veremos cada um desses serviços, 
então, sem perder tempo, vamos nessa. 


11.1 Criando a classe abstrata ServiceAbstract e 
o serviço TipoUsuarioService 


Primeiramente, vamos criar o nosso diretório que deverá 
conter os nossos serviços. Dentro do diretório 
src/App/src , vamos criar o diretório service conforme 
mostra a imagem a seguir: 
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Figura 11.1: Criando o diretório Service 


Dentro dele, vamos criar o diretório Factory que será 
responsável por conter as Factories dos nossos serviços. 
Crie o diretório Factory conforme mostra a imagem a 


seguir: 
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Figura 11.2: Criando o diretório Factory 





Com a criação do diretório Factory , podemos realizar a 
criação do nosso primeiro serviço que realizará as 
operações de acordo com o que definirmos nele e com o 
que já definimos em nossa regra de negócio em nosso 
repositório TipousuarioRepository . 


O serviço TipoUsuarioService sera responsável por 
possuir as operações que farão o gerenciamento dos tipos 
de usuários que cadastrarmos em nossa aplicação. E 
através dele que vamos inserir, alterar, listar, deletar os 
dados pertencentes a esse serviço. 


Então, vamos criar nosso serviço, para isso, dentro do 
diretório Service crie a classe  TipousuarioService 
conforme mostra a imagem a seguir: 
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Figura 11.3: Criando o servico TipoUsuarioService 


Logo em seguida vamos criar uma classe abstrata 
chamada  serviceabstract que será responsável por 
conter os métodos padrões que poderão ser utilizados por 
todos os serviços que criarmos por meio do conceito de 





herança, ou seja, estendendo a classe abstrata. Seu 
diretório service deve conter os seguintes arquivos até o 
momento: 


¥ livro-zend-expressive 


Doctrine 


i” 


Figura 11.4: Criando a classe abstrata ServiceAbstract 





Agora vamos ver o código completo de cada uma das 
classes que criamos anteriormente, entender cada 
método que elas possuem e qual é a finalidade de cada 
um. 


Confira a seguir o código completo da classe abstrata 
ServiceAbstract : 


<?php 
declare(strict types=1); 
namespace App\Service; 


use Doctrine\ORM\EntityManager; 
use Zend\Hydrator\ClassMethods; 


yr 
* Class ServiceAbstract 
* @package App\Service 
=F 
abstract class ServiceAbstract 
{ 
/** 
* @var EntityManager 
-7 
protected $em; 


pa 
* @var string 
nd 
protected $entity; 


pe 
* ServiceAbstract constructor. 
* @param EntityManager $em 
ry 


public function | construct(EntityManager $em) 


{ 


$this->em = $em; 


} 
jee 
* @throws \Exception 
ad 
public function getAll() 
{ 
try { 
$repository = $this->em->getRepository($this- 
>entity); 
return $repository->getAll(); 
+ catch (\Exception $e) { 
throw $e; 
} 
} 
jee 


* @param int $id 
* @return mixed 
* @throws \Exception 


+7 
public function getOne(int $id) 
{ 
try { 
$repository = $this->em->getRepository($this- 
>entity); 
return $repository->getOne($id); 
+ catch (\Exception $e) { 
throw $e; 
} 
} 
jee 


* @return array 


* @throws \Exception 


-7 
public function getAllwWwithDQL(): array 
{ 
try { 
$repository = $this->em->getRepository($this- 
>entity); 
return S$repository->getAllwithDQL(); 
+ catch (\Exception $e) { 
throw $e; 
} 
} 
jee 


* @param int $id 
* @return array 
* @throws \Exception 
di 
public function getOnewithDQL(int $id): array 
{ 
try { 
$repository = $this->em->getRepository($this- 
>entity); 
return $repository->getOnewithDQL($id); 
+ catch (\Exception $e) { 
throw $e; 


pur 

* @param array $data 

* Qreturn mixed 

* (throws \Exception 

dá 
public function insert(array $data) 
{ 

try { 


$entity = new $this->entity(); 


$classMethods = new ClassMethods(); 
$classMethods->hydrate($data, $entity); 


$this->em->persist(Sentity); 
$this->em->flush(); 


return $entity->toArray(); 
+ catch (\Exception $e) { 
throw $e; 


/** 
* @param array $data 
* @return array 
* @throws \Exception 
di 
public function update(array $data): array 
{ 


try { 
$entity = $this->em->getReference($this- 
>entity, $data['id']); 


$classMethods = new ClassMethods(); 
$classMethods->hydrate($data, $entity); 


$this->em->persist($entity); 
$this->em->flush(); 


return $entity->toArray(); 
+ catch (Exception $e) { 
throw $e; 


ye 
* (param int $id 
* (return mixed 
* (throws Exception 
a 
public function delete(int $id) 


{ 


try { 
$entity = $this->em->getReference($this- 


>entity, $id); 


$this->em->remove(Sentity); 
$this->em->flush(); 


return $entity; 
} catch (\Exception $e) { 
throw $e; 


} 


Vamos entender o que significa o código dessa classe. A 
primeira coisa a notar é a palavra-chave abstract antes 
da definição do nome da classe. A palavra abstract está 
informando que a classe que estamos criando é uma 
classe abstrata, mas o que isso significa”? Significa que a 
classe não pode ser instanciada e para ter acesso aos 
métodos e propriedades dela, deve-se estendé-la/herda-la 
com o uso da palavra extends , isso é o que chamamos 
de herança. Veremos o funcionamento da herança na 
prática em nossos serviços. 


Caso não tenha ficado clara a explicação sobre a classe 
abstrata, veja o exemplo a seguir para fixar o 
conhecimento: 


<?php 


abstract class AbstractService 


{ 
public $entity = 'Entidade'; 


public $em = 'EntityManager';, 


class Service 


{ 


private $entity; 
private $em; 


public function __construct() 


{ 


$abstractService = new AbstractService(); 
$this->entity = $abstractService->entiy; 
$this->em = $abstractService->em; 


public function getEntity() 
{ 


return $this->entity; 


public function getEm() 
{ 


return $this->em; 


$service = new Service(); 


Tente reproduzir esse exemplo e você receberá um erro 
fatal, informando que não é possível instanciar a classe 
AbstractService , isso porque ela é uma classe abstrata e 
não permite criar um objeto utilizando a palavra new. O 


unico modo de conseguir utilizar as propriedades public 
$entity @ public $em que está definida na classe 
AbstractService é através da herança. Veja o código a 
seguir, que torna isso possível: 


<?php 


abstract class AbstractService 


{ 
public $entity = 'Entidade'; 
public $em = 'EntityManager'; 
} 
class Service extends AbstractService 
{ 
public function getEntity() 
{ 
return $this->entity; 
} 
public function getEm() 
{ 
return $this->em; 
} 
} 


$service = new Service(); 
echo $service->getEntity(); 
echo $service->getEm(); 
//Ou ainda... 

echo $service->entity; 

echo $service->em; 


Veja que por meio da herança com a palavra extends 
conseguimos ter acesso às propriedades public S$entity 
e public $em e ainda conseguimos manipulá-las em 
nossa classe concreta service . Pense em classe abstrata 


como sendo algo que não se pode ver, você sabe que 
existe mas não pode tocar, no caso, não pode instanciar - 
é bem por aí. 


Outro ponto importante a ser observado é que definimos 
as propriedades como protected ou protegido em 
portugués, mas os métodos da classe como public ou 
público. Mas o que isso significa? Significa que somente 
as classes que herdam/estendem a classe abstrata 
podem ter acesso aos métodos e propriedades. O método 
construtor _ construct recebe como atributo um objeto 
EntityManager do Doctrine. 


e protected $em - Essa propriedade será injetada por 
meio do parâmetro do método construtor que 
injetara o objeto EntityManager para que possa ser 
utilizado pelos métodos da classe. 


e protected $entity - Essa propriedade receberá o 
nome completo de uma entidade, ou seja, o nome 
da entidade incluindo o seu namespace . 


e getall() - Obtém do repositório todos os dados 
pertencentes a uma determinada entidade, esse 
método retornará todos os dados de acordo com o 
que foi definido no método dentro do repositório. 


e getOne(int $id) - Obtém apenas um registro de 
acordo com o que foi definido no método dentro do 
repositório. O registro será obtido através do id que 
deverá ser informado como parâmetro do método. 
Você pode estar se perguntando: mas qual 
repositório? A resposta é simples, o repositório da 
entidade que vamos definir em cada serviço. 


getAllwithbQL() - Assim como o método getAll , 
retorna todos os dados de uma determinada 
entidade, porém a diferença é que no repositório é 
utilizada a linguagem por , esse método está 
presente para que o leitor possa entender a 
diferença entre utilizar a linguagem por e os 
métodos fornecidos pelo Doctrine. 


getOnewithDQL (int $id) - Também funciona como o 
método getone e a sua diferença está no método 
definido no repositório, que utiliza a linguagem bat 
para obter os dados do registro. Esse método 
também está presente para que o leitor possa 
entender a diferença entre utilizar a linguagem DaL 
e os métodos fornecidos pelo Doctrine. 


insert(array $data) - Esse método é responsável 
por realizar a inserção de um registro no banco de 
dados. Um ponto importantissimo a ser observado é 
a utilização do componente já conhecido, Zend 
Hydrator, que realizará a atribuição dos dados de 
forma mais performática e eficaz, como já vimos 
anteriormente. Esse método recebe como parâmetro 
um array de dados que deve conter o nome de 
cada propriedade que foi definida na classe, 
possibilitando que o Zend Hydrator realize a 
atribuição automática dos dados. 


update(array $data) - Realiza a atualização dos 
dados de um determinado registro de uma 
determinada entidade. Esse método recebe um 
array de dados como parâmetro e dentro desse 
conjunto de dados deve existir uma chave chamada 
id contendo o id do registro a ser alterado. E 


através dessa chave que a alteração dos dados será 
possível. Outro ponto a ser observado é a utilização 
do metodo getReference , que é disponibilizado pelo 
objeto EntityManager . Esse método é responsável 
por recuperar as informações da entidade por meio 
do Proxy, que é gravado lá na pasta de cache . Isso 
faz com que a consulta se torne mais ágil ao realizar 
a busca pela informação desejada. 


e delete(int $id) - Realiza a exclusão de um 
determinado registro do banco de dados de uma 
determinada entidade. Esse método recebe como 
parâmetro um id , que deve ser informado no 
momento de sua utilização. Assim como no método 

update , aqui também utilizamos o método 
getReference do objeto EntityManager . 


Todos os métodos definidos em nossa classe abstrata 
poderão ser acessados pelas nossas classes de serviços 
por meio da herança, como já falamos. Agora que 
conhecemos a nossa classe serviceabstract que será a 
base para todas as demais classes de serviços que 
criamos, está na hora de conhecermos a nossa primeira 
classe de serviço. 


Confira a seguir o código completo da classe 
TipoUsuarioService : 


<?php 
declare(strict_types=1); 
namespace App\Service; 


use App\Entity\TipoUsuario; 


jee 
* Class TipoUsuarioService 
* @package App\Service 
y 

class TipoUsuarioService extends ServiceAbstract 


{ 


protected $entity = TipoUsuario::class; 


} 


Jhones, é só isso? Sim, meu amigo, o código desse e dos 
demais serviços serão simples como esse, com poucas 
linhas de código. Isso porque criamos uma classe abstrata 
que servirá como base para todos os serviços que 
criarmos, e como herdamos a classe base, teremos todos 
os métodos e propriedades disponíveis em nossa classe 
concreta TipoUsuarioService . 


No codigo da nossa classe TipoUsuarioService , perceba 
que estamos utilizando extends ServiceAbstract que 
indica que estamos herdando a classe serviceabstract € 
por meio dessa herança teremos acesso a todos os 
métodos que criamos na classe abstrata e todas as 
propriedades. 


Perceba que estamos utilizando a propriedade protected 
$entity , que definimos lá na nossa classe abstrata, e 
estamos atribuindo a ela o nome completo da nossa 
entidade TipoUsuario por meio do codigo 
Tipousuario::class . Essa é a entidade que será 
correspondente ao serviço TipoUsuarioService . 


Com isso, finalizamos a criação do nosso primeiro serviço 
que herda as características da nossa classe abstrata. Na 
próxima seção vamos criar O serviço UsuarioService . 


11.2 Criando o serviço UsuarioService 


Antes de mais nada, esse serviço será responsável pelas 
operações destinadas aos usuários da nossa aplicação. 
Assim como o anterior, esse serviço também realizará as 
operações de CRUD pertencentes ao repositório 

UsuarioRepository e outras que possam surgir ou que 
você deseje criar. 


Então, vamos criar O servico UsuarioService em nosso 
diretório service , assim como fizemos anteriormente com 
O Serviço TipoUsuarioService , conforme mostra a imagem 
a seguir: 
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Figura 11.5: Criando o serviço UsuarioService 


Após a criação do serviço, vamos ver o código completo a 





seguir: 

<?php 

declare(strict types=1); 
namespace App\Service; 


use App\Entity\TipoUsuario; 
use App\Entity\Usuario; 
use Zend\Hydrator\ClassMethods; 


J = 
* Class UsuarioService 
* @package App\Service 
*/ 
class UsuarioService extends ServiceAbstract 


{ 


protected $entity = Usuario::class; 


fx 

* @param array $data 

* @return mixed 

* @throws \Exception 

RA 
public function insert(array $data) 
{ 


try { 
$entity = new $this->entity(); 


$userType = $this->em- 
>getReference(TipoUsuario::class, $data['tipoUsuario']); 

$data[ 'tipoUsuario'] = $userType; 

$data[ 'dataNascimento'] = new 
\DateTime($data['dataNascimento']); 


$classMethods = new ClassMethods(); 


$classMethods->hydrate($data, $entity); 


$this->em->persist($entity); 
$this->em->flush(); 


return $entity->toArray(); 
+ catch (NException $e) { 
throw S$e; 


paz 

* @param array $data 

* @return array 

* (throws \Exception 

E 
public function update(array $data): array 
{ 


try { 
$entity = $this->em->getReference($this- 


>entity, $data['id']); 


if (!empty($data['tipoUsuario'])) { 
$userType = $this->em- 
>getReference(TipoUsuario::class, $data['tipoUsuario']); 
$data[ 'tipoUsuario'] = $userType; 


if (!empty($data['dataNascimento'])) { 
$data[ 'dataNascimento'] = new 
\DateTime($data[ 'dataNascimento']); 


} 


$classMethods = new ClassMethods(); 
$classMethods->hydrate($data, $entity); 


$this->em->persist($entity); 


$this->em->flush(); 


return $entity->toArray(); 
+ catch (NException $e) { 
throw S$e; 


} 


Vamos entender por que esse serviço é um pouco maior 
do que o serviço  TipoUsuarioService . Assim como 
anteriormente, perceba que estamos herdando a classe 
Serviceabstract que já provê diversos métodos que 
poderemos e vamos utilizar em nossa aplicação. 


Perceba que os únicos métodos que estamos 
sobrescrevendo sao o insert(array $data) e o 

update(array $data) . Mas você sabe o motivo dessa 
sobrescrita, já que ambos estão em nossa classe 
abstrata? É bem simples: o método presente em nossa 
classe abstrata é genérico e mais simples, mas serve 
perfeitamente para serviços que não necessitam realizar a 
inserção ou alteração de dados que possuam algum tipo 
de dependência que deva ser processada antes, para que 
se tenha o efeito esperado, como o relacionamento. Em 
nosso serviço temos uma dependência que é obter o 
registro do tipo de usuário que deve ser informado no 
momento da inserção/alteração do registro. Se omitirmos 
esse dado ao realizarmos a inserção ocorrerá erro, pois 
esse dado é obrigatório. 


Por exemplo, perceba que quando criamos a entidade 
Usuario definimos um relacionamento com a entidade 
Tipousuario . Dessa forma, em nosso serviço, isso 

também deve ser refletido para que, no momento em que 


realizarmos a inserção ou alteração do registro, não 
ocorram erros informando que o campo tipo usuario id 
no banco de dados não pode ser nulo. 


Em nosso serviço, isso é feito através do código suserType 
= $this->em->getReference(TipoUsuario::class, 
$data['tipoUsuario']) , que diz que estamos buscando, 
em nosso cache de proxies do Doctrine, o tipo de usuario 
correspondente ao valor passado no corpo da requisição. 
Por exemplo, se passarmos o valor 1, será com base 
nesse valor que o Doctrine fará a busca no cache e 
retornará um objeto correspondente à entidade que 
passamos como primeiro parâmetro. Por fim, o resultado 
obtido será armazenado na variável guserType . Em todo 
esse processo, o Doctrine não realizará nenhuma 
consulta no banco de dados, tornando o procedimento 
muito mais eficiente. 


Por fim, com o código $data['tipoUsuario'] = $userType , 
estamos passando o resultado obtido, armazenado na 
variável $userType , para a nossa propriedade 
tipoUsuario , que foi definida em nossa entidade usuario . 
É importante ser exatamente o mesmo nome, porque o 
Zend Hydrator fará a atribuição dos dados com base no 
nome das propriedades da entidade, caso o nome da 
propriedade esteja incorreto, a atribuição não será 
realizada, então atente-se bem a isso. 


Logo em seguida, temos o código $data['dataNascimento' ] 
= new \DateTime($data['dataNascimento']) que é 
responsável por realizar a atribuição da data de 
nascimento informada na chave dataNascimento dO array 
de dados. Se você for olhar na entidade, verá que essa 
propriedade é do tipo DateTime , e estamos setando-a aqui 


porque precisamos converter a string da data de 
nascimento que será informada no corpo da requisição no 
formato DateTime . 


O codigo $userType = $this->em- 
>getReference(TipoUsuario::class, $data[ 'tipoUsuario']) 
presente no método insert(array $data) e o trecho 

$data[ 'dataNascimento'] = new 
WDateTime($data['dataNascimento']) também estão 


presentes no método update(array $data) e possuem 
exatamente o mesmo funcionamento, por esse motivo não 
serão explicados novamente. 


No método update(array $data) , a novidade é o código 

$entity = $this->em->getReference($this->entity, 
$data['id']) , que possui o mesmo funcionamento 
descrito anteriormente, porém, nesse caso, estamos 
buscando através do parâmetro $data['id'] contido na 
entidade Usuario o registro correspondente ao id 
informado para realizarmos a alteração. 


Apesar de o código ser um pouco maior do que o do 
serviço TipoUsuarioService , seu funcionamento é 
bastante simples. Agora que finalizamos a construção do 
nosso serviço UsuarioService , Na próxima seção vamos 
criar o nosso último serviço, O MensagemService , que tera 
um código bem semelhante ao nosso serviço de usuário. 


11.3 Criando o serviço MensagemService 


Esse serviço será responsável por armazenar em nosso 
banco de dados as mensagens que os usuários enviarão 


entre si para que se possa obter um histórico de 
mensagens trocadas entre eles. Assim como os serviços 
anteriores, este também realizará as operações de CRUD 
pertencentes ao repositório MensagemRepository e outros 
tipos de operações que possam surgir ou as que você 
desejar criar. 


Como de costume, antes de mais nada vamos criar o 
nosso serviço  MensagemService em nosso diretório 
Service , conforme mostra a imagem a seguir: 


livro-zend-expressive 


=. 
epee eh da 
LOC TIME 


Figura 11.6: Criando o serviço MensagemService 
Vamos analisar o código completo a seguir: 


<?php 





declare(strict types=1); 
namespace App\Service; 


use App\Entity\Mensagem; 
use App\Entity\Usuario; 
use Zend\Hydrator\ClassMethods; 


j ** 
* Class MensagemService 
* @package App\Service 
*/ 
class MensagemService extends ServiceAbstract 


{ 


protected $entity = Mensagem: :class; 


fr 

* @param array $data 

* @return mixed 

* @throws \Exception 

À 
public function insert(array $data) 
{ 


try { 
$entity = new $this->entity(); 


$user = $this->em- 
>getReference(Usuario::class, S$data['usuario']); 

$data[ 'usuario'] = $user; 

$data[ 'dataMensagem'] = new \DateTime('now'); 


$classMethods = new ClassMethods(); 
$classMethods->hydrate($data, $entity); 


$this->em->persist($entity); 
$this->em->flush(); 


return $entity->toArray(); 
+ catch (NException $e) { 
throw $e; 


fr 

* @param array $data 

* @return array 

* @throws \Exception 

<7 
public function update(array $data): array 
{ 


try 4 
$entity = $this->em->getReference($this- 


>entity, $data['id']); 


if (!empty($data[ 'usuario'])) { 
$user = $this->em- 
>getReference(Usuario::class, $data['usuario']); 
$data[ 'usuario'] = $user; 


$classMethods = new ClassMethods(); 
$classMethods->hydrate($data, $entity); 


$this->em->persist($entity); 
$this->em->flush(); 


return $entity->toArray(); 
+ catch (NException $e) { 
throw $e; 


} 


Perceba que o código é muito semelhante ao do serviço 


UsuarioService porque nesse caso também fizemos a 
sobrescrita dos métodos insert(array $data) e 
update(array $data) . Desse modo, não serão explicados 
novamente os dois métodos sobrescritos, porém perceba 
que atribuímos à nossa propriedade protected $entity a 
entidade Mensagem::class , ficando da seguinte maneira: 
protected $entity = Mensagem: :class . Isso foi feito porque 
nosso serviço MensagemService trabalhará com a entidade 
correspondente, que é a entidade mensagem . Cada serviço 
possui a sua entidade correspondente, logo não estaria 
correto chamarmos a entidade desse serviço como sendo 
Usuario OU TipoUsuario pois não são pertencentes a 
esse serviço. 


Nosso trabalho foi poupado graças à nossa classe 
abstrata. Imagine ter que escrever para cada serviço os 
mesmos métodos alterando apenas a entidade? Seria 
uma tarefa cansativa e com duplicidade de código! 
Sempre que puder, utilize uma classe base e ou uma 
interface, isso fará com que sua aplicação seja bem mais 
flexível. 


Agora que criamos todos os nossos serviços, devemos 
criar as suas Factories (fábricas) que serão responsáveis 
por retornar o objeto do serviço em questão por meio do 
contêiner de injeção de dependência. 


11.4 Criando a Factory 
TipoUsuarioServiceFactory 


Essa Factory vai retornar uma instância do serviço 
TipoUsuarioService que poderá ser utilizada por toda a 


aplicação. 


Vamos criar nossa Factory TipoUsuarioServiceFactory 
dentro do nosso diretório Service/Factory conforme 
mostra a imagem a seguir: 
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Figura 11.7: Criando a Factory TipoUsuarioServiceFactory 


Os códigos das nossas Factories serão bem simples, 
como você pode ver a seguir: 


<?php 


declare(strict types=1); 
namespace App\Service\Factory; 


use App\Service\TipoUsuarioService; 
use Doctrine\ORM\EntityManager ; 
use Interop\Container\ContainerInterface; 


AER 
* Class TipoUsuarioServiceFactory 
* (package App\Service\Factory 
rd 

class TipoUsuarioServiceFactory 


{ 
FER 
* Qparam ContainerInterface $container 
* @return TipoUsuarioService 
sl 
public function | invoke(ContainerInterface 
$container): TipoUsuarioService 


{ 
$em = $container->get(EntityManager::class); 
return new TipoUsuarioService($em) ; 


} 


Como você pode ver, só estamos utilizando o método 
__invoke__ assim como já fizemos anteriormente para 
configurarmos o Doctrine. Nesse metodo, estamos 
passando como parâmetro apenas a interface 
ContainerInterface , que é a responsável por prover os 
métodos que são utilizados pelo contêiner de injeção de 
dependências. 


Definimos o tipo de retorno do método como sendo um 


objeto do tipo Tipousuarioservice e, no momento da 
criação desse objeto, estamos passando um objeto 
EntityManager que foi obtido através do código $em = 
$container->get(EntityManager::class) . Esse objeto é 
aquele que definimos quando estavamos criando a 
configuração do Doctrine, lembra? Como o registramos 
em nosso arquivo configProvider.php , podemos utilizá-lo 
de qualquer lugar da aplicação, desde que consigamos 
utilizar o contêiner de injeção de dependência. 


Não tem muito segredo, não é mesmo? Da mesma 
maneira faremos com os demais serviços e o código será 
muito semelhante, mudando apenas o objeto a ser 
retornado pela Factory. 


11.5 Criando a Factory UsuarioServiceFactory 


Essa Factory é responsável por retornar uma instância do 

serviço UsuarioService . Crie a Factory 
UsuarioServiceFactory dentro do nosso diretório 

Service/Factory conforme mostra a imagem a seguir: 
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Figura 11.8: Criando a Factory UsuarioServiceFactory 
Confira a seguir o código completo dessa Factory: 
<?php 
declare(strict_types=1) ; 
namespace App\Service\Factory; 


use App\Service\UsuarioService; 


use Doctrine\ORM\EntityManager ; 
use Interop\Container\ContainerInterface; 


fre 
* Class UsuarioServiceFactory 
* @package App\Service\Factory 
*/ 

class UsuarioServiceFactory 


{ 
fr 
* @param ContainerInterface $container 
* @return UsuarioService 
*/ 
public function | invoke(ContainerInterface 
$container): UsuarioService 


{ 
$em = $container->get(EntityManager::class); 
return new UsuarioService($em); 


} 


Como podemos ver, o código é pequeno e semelhante ao 
da Factory anterior, a unica diferença é o objeto a ser 
retornado, que nesse caso é uma instância do serviço 
UsuarioService . 


11.6 Criando a Factory 
MensagemsServiceFactory 


Essa Factory será responsável por retornar uma instância 

do serviço MensagemService . Crie a Factory 
MensagemServiceFactory em nosso diretorio 

Service/Factory conforme mostra a imagem a seguir: 
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Figura 11.9: Criando a Factory MensagemServiceFactory 


Vamos ver a seguir código completo da nossa Factory 
MensagemServiceFactory : 


<?php 


declare(strict_types=1) ; 


namespace App\Service\Factory; 


use App\Service\MensagemService; 
use Doctrine\ORM\EntityManager ; 
use Interop\Container\ContainerInterface; 


JER 
* Class MensagemServiceFactory 
* @package App\Service\Factory 
a 

class MensagemServiceFactory 


{ 
paz 
* Qparam ContainerInterface $container 
* (return MensagemService 
*/ 
public function | invoke(ContainerInterface 
$container): MensagemService 


{ 


$em = $container->get(EntityManager::class); 
return new MensagemService(S$em); 


} 


Perceba que novamente não houve grandes alterações e 
que o código é bem semelhante aos anteriores. Qual é a 
unica diferença? Se você pensou que é apenas o objeto 
que é retornado pela Factory, você acertou! Nessa 
Factory estamos retornando o objeto do serviço 
MensagemService . 


Com isso, finalizamos a criação da nossas Factories, mas 
ainda nao acabamos. Para finalizarmos o capitulo, falta 
registrarmos nossos serviços em nosso arquivo de 
configuração oonfigProvider.php e é exatamente isso que 
faremos na próxima seção. 


11.7 Registrando os serviços 


Devemos registrar nossos serviços para que eles possam 
funcionar corretamente e estejam disponíveis em toda a 
aplicação. 


Para ISSO, abra O seu arquivo 
src/App/src/ConfigProvider.php œe localize o método 
getDependencies() . No array que é retornado pelo 

método, localize a chave Factories e vamos registrar 

nossos serviços com nossas Factories. 


Confira a seguir o código completo do método 
getDependencies() contendo o registro dos nossos 
serviços: 


<?php 
JR 
* Returns the container dependencies 
*/ 
public function getDependencies() : array 
{ 
return [ 


'invokables' => [ 
Handler\PingHandler::class => 
Handler\PingHandler::class, 
l, 
'Factories' => [ 
Handler\HomePageHandler::class => 
Handler\HomePageHandlerFactory::class, 
Handler\TestDoctrineConnectionHandler::class 
=> 
Handler \Factory\TestDoctrineConnectionHandlerFactory::cla 
SS, 


//Registrando Servicos 


Service\TipoUsuarioService::class => 
Service\Factory\TipoUsuarioServiceFactory::class, 

Service\UsuarioService::class => 
Service\Factory\UsuarioServiceFactory::class, 

Service\MensagemService::class => 
Service\Factory\MensagemServiceFactory::class 


il 
1; 
} 


Perceba que não é complicado registrar os serviços. Um 
ponto importante a ser mencionado é que não 
necessariamente você precisa definir o nome do registro 
como sendo o nome completo da classe, por exemplo 

Service\TipoUsuarioService::class . Se você quiser 
chamar apenas de tipo usuario service ou um outro 
nome qualquer de sua escolha, você pode fazer isso sem 
problemas, só não esqueça de chamar o nome correto no 
momento em que você for utilizar o serviço através do 


contêiner de injeção de dependência, combinado? 
Conclusão 


Chegamos ao final de mais um capítulo no qual vimos 
exemplos de como criarmos serviços, Factories e registrar 
nossos serviços para que possam ser utilizados por toda a 
aplicação através do contêiner de injeção de 
dependência. Vimos aqui como uma classe base pode 
nos ajudar, aumentando a reusabilidade do código e 
evitando a duplicidade. Vale ressaltar que existem 
inúmeras maneiras de se fazer isso, então cabe a você se 
aprofundar, criar sua própria lógica e decidir a melhor 
maneira de fazer em sua aplicação. 


No próximo capítulo, vamos criar e registrar nossos 


handlers/middlewares/actions (qualquer um dos termos 
está correto e pode ser utilizado), então, siga em frente e 
vamos nessa! 


CaríruLo 12 
Criando e registrando Handlers de 
tipos de usuário 


Agora que criamos e registramos os nossos serviços, 
temos que criar os nossos Handlers/Middlewares que 
serão responsáveis por receber as requisições enviadas 
pela aplicação cliente, fazer o tratamento adequado e 
retornar uma resposta para o cliente. 


Esse repasse será feito até que um Handler/Middleware 
seja capaz de tratar adequadamente a requisição com 
seus dados. 


Nas próximas seções, veremos como criar cada 
Handler/Middleware da nossa aplicação, como serão 
muitos Handlers/Middlewares o assunto será dividido em 
três capítulos. 


O que É HANDLER/MIDDLEWARE? 


Handler/Middleware são manipuladores que possuem 


como responsabilidade realizar o tratamento de 
alguma informação, ou repassá-la para frente, caso 
não consiga realizar o tratamento adequado. 





Antes de prosseguirmos, será necessário instalar o 
componente Zend Json em nossa aplicação, porque ele 
será responsável por decodificar a string em JSON 
convertendo-a em array. 


O que É ZEND JSON? 


É um componente do Zend Framework responsável 


por realizar a codificação de dados em formato JSON 
e também a decodificação do JSON em outros 
formatos, como o array, por exemplo. 





Para clonar o componente, execute o comando a seguir: 
composer require zendframework/zend-json 


Após executar o comando anterior, o componente Zend 
Json será instalado e injetado automaticamente no 
arquivo de configuração. Se a instalação ocorreu tudo 
bem, você deverá ter uma saída semelhante à da imagem 
a seguir: 
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Figura 12.1: Clonando e registrando o componente Zend Json 


Após a instalação do componente Zend Json, podemos 
seguir em frente para criarmos os Handlers. 


12.1 Criando O Handler 
TipoUsuarioListarHandler 


O primeiro Handler/Middleware que vamos criar é o 
TipoUsuarioListarHandler , que será responsável por listar 
todos os tipos de usuários disponíveis em nosso banco de 
dados. 


Antes de criarmos o nosso Handler propriamente dito, 
vamos criar uma classe abstrata que será responsável por 
conter propriedades e métodos padrões que servirão 
como base para todos os nosso handlers subsequentes. 
Para isso, vamos criar a nossa classe Handlerabstract 
em nosso diretório src/App/src/Handler , conforme mostra 
a imagem a seguir: 
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Figura 12.2: Criando a classe abstrata HandlerAbstract 


O código desse Handler é bastante simples e você pode 
conferir a seguir: 


<?php 


declare(strict_types=1); 


namespace App\Handler; 
use InteropiContaineriContainerInterface; 


/** 
* Class HandlerAbstract 
* @package App\Handler 
=F 

abstract class HandlerAbstract 


{ 
/** 
* @var ContainerInterface 
"y 
protected $container; 


jer 
* HandlerAbstract constructor. 
* @param ContainerInterface $container 
"7 
public function _ construct(ContainerInterface 
$container) 


{ 


$this->container = $container; 


} 


Como vocé pode ver, nossa classe abstrata nao e 
complexa e possui apenas uma propriedade protected 
$container do tipo InteropNContaineriContainerInterface , 
que será responsável por armazenar o objeto do nosso 
contêiner de injeção de dependência. Essa propriedade 
será populada no momento em que o construtor da classe 
for chamado. 


Veja que o nosso método _ construct(ContainerInterface 
$container) recebe como parâmetro um objeto do tipo 


Interop\Container\ContainerInterface e realiza a 
atribuição desse objeto à nossa propriedade $this- 
>container . Isso é feito para que nossos Handlers possam 
utilizar os nossos serviços registrados em nosso contêiner 
de injeção de dependência. Você verá como será utilizado 
no passo adiante. 


Agora que temos nossa classe abstrata que proverá 
métodos e propriedades em comum para os nossos 
Handlers utilizarem, vamos criar nossa primeira classe de 
Handler. Como de costume, vamos criar um diretório 
dentro de src/App/src/Handler chamado Tipousuario , 
que armazenará todas as nossas classes de Handlers de 
tipo de usuário. Em seguida, dentro do diretório que 
acabamos de criar, crie uma classe chamada 
TipoUsuarioListarHandler , conforme mostra a imagem a 
seguir: 
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Figura 12.3: Criando o Handler TipoUsuarioListarHandler 


Agora que vocé ja criou a classe de Handler, vamos 
analisar o código a seguir para você entender o 
funcionamento. Veja o código do Handler 
TipoUsuarioListarHandler a seguir: 


<?php 
declare(strict types=1); 


namespace App\Handler\TipoUsuario; 


use App\Handler\HandlerAbstract; 

use App\Service\TipoUsuarioService; 

use Psr\Http\Message\ResponselInterface; 

use Psr\Http\Message\ServerRequestinterface; 
use Psr\Http\Server\RequestHandleriInterface; 
use Zend\Diactoros\Response\JsonResponse; 


IER 
* Class TipoUsuarioListarHandler 
* @package App\Handler\TipoUsuario 
*/ 
class TipoUsuarioListarHandler extends HandlerAbstract 
implements RequestHandlerInterface 
{ 
f= * 
* @param ServerRequestInterface $request 
* @return ResponseInterface 
A 
public function handle(ServerRequestInterface 
$request): ResponseInterface 
{ 
$service = $this->container- 
>get (TipoUsuarioService::class); 
$resultwithDQL = $service->getAll(); 
$resultwithoutDQL = $service->getAl1WithDQL(); 


return new JsonResponse([ 
'result with dql' => $resultWithDQL, 
'result without dql' => $resultwithoutDQL 
1); 


} 


y 


A primeira coisa a notar nesse código é a herança da 
nossa classe Handlerabstract e a implementação da 
interface RequestHandlerInterface , que são realizados 
pelo código extends HandlerAbstract implements 


RequestHandlerInterface . 


Como dito anteriormente, nossa classe Handlerabstract 
possui propriedades e métodos que são comuns entre 
todos os Handlers que vamos criar. A implementação da 
interface 'RequesHandlerInterface proverá o método 
handle(ServerRequestInterface $request) , No qual vamos 
trabalhar. Esse método é responsável por receber a 
requisição e realizar ou não o tratamento adequado das 
informações, retornando ou não uma resposta para o 
cliente, em formato json . Perceba que o tipo de retorno 
esperado pelo método handle(ServerRequestInterface 
$request) é um objeto do tipo ResponseInterface , OU seja, 
tem que ser um objeto que tenha implementado a 
interface ResponseInterface do pacote Psr\Http\Message . 


Dentro do metodo handle(ServerRequestInterface 
$request) temos poucas linhas de código. A primeira parte 
a se notar é a utilização do código $service = $this- 
>container ->get (TipoUsuarioService: :class) Nele, 
estamos utilizando a propriedade $container , que fol 
herdada de nossa classe abstrata HandlerAbstract , bem 
como o método get presente no objeto de nossa 
propriedade. Esse método é o responsável por obter o 
nosso serviço TipoUsuarioService registrado em nosso 
contêiner de injeção de dependência em nosso arquivo 
ConfigProvider , e armazenar o objeto do nosso serviço 
na variável $service . 


Os próximos trechos a se observar são $resultwithDQL = 
$service->getAll() e $resultwithoutDQL = $service- 
>getAllwithDQL() . Nesses códigos, estamos realizando a 
consulta para obter todos os tipos de usuários utilizando 
os métodos getall() e  getAllwithoutpboL de nossos 


serviços. Estamos armazenando o resultado obtido nas 
variáveis $resultwithDQL e $resultwithoutDQL 
respectivamente. 


Por fim, temos o trecho de retorno da resposta: 


return new JsonResponse( [ 
“result with dql' => $resultWithDQL, 
'result without dql' => $resultwithoutDQL 
], 200); 


Como dito anteriormente, temos que retornar um objeto 
do tipo ResponseInterface . Se você analisar a classe 
JsonResponse que estamos instanciando no momento do 
retorno de nosso método, verá que ela estende a classe 

Zend\Diactoros\Response , que por si implementa a 
interface ResponseInterface , permitindo que ela seja 
valida para ser utilizada como retorno do método. 


Como primeiro parámetro da classe JsonResponse 
estamos passando um array de dados que são 
exatamente os dados obtidos das consultas realizadas 
anteriormente. Esses dados serão convertidos em Json 
no momento em que a resposta for enviada para a 
aplicacáo cliente. O segundo parámetro que estamos 
passando é o tipo de status da resposta. Como náo 
estamos esperando que ocorram erros, o código de 
resposta esperado é o 200. 


Finalizamos aqui a criação do nosso Handler 
TipoUsuarioListarHandler . Como você pôde ver, nao foi 
complicado, nem complexo e o código ficou bem 
pequeno. Na próxima seção vamos criar a Factory do 
nosso Handler. 


Criando a Factory TipoUsuarioListarHandlerFactory 


Assim como temos feito com todos os nossos serviços, 
também devemos criar nossas Factories e registrar em 
nosso contêiner de injeção de dependência, para que o 
Zend Expressive possa interpretar e realizar o 
processamento. 


Crie um diretório chamado Tipousuario dentro do diretório 

src/App/src/Handler/Factory e, em seguida, crie a classe 
de Factory TipoUsuarioListarHandlerFactory , conforme 
mostra a imagem a seguir: 
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Figura 12.4: Criando a Factory TipoUsuarioListarHandlerFactory 


Após a criacáo da Factory, veja como é seu código 


completo a seguir: 

<?php 

declare(strict types=1); 

namespace App\Handler\Factory\TipoUsuario; 


use App\Handler\TipoUsuario\TipoUsSuarioListarHandler; 
use Interop\Container\ContainerInterface; 


per 
* Class TipoUsuarioListarHandlerFactory 
* (package App\Handler\Factory\TipoUsuario 
"7 

class TipoUsuarioListarHandlerFactory 


{ 
per 
* @param ContainerInterface $container 
* (return TipoUsuarioListarHandler 
a É 
public function _ invoke(ContainerInterface 
$container): TipoUsuarioListarHandler 


{ 


return new TipoUsuarioListarHandler(S$container ); 


} 


O código da nossa Factory é bem simples e, inclusive, 
todas as Factories que criarmos terão um código simples 
como esse. O único objetivo dessa Factory é retornar a 
instância da classe TipousuarioListarHandler , que será 
utilizada pela aplicação. Esse objeto retornado é o que 
conseguimos utilizar quando realizamos a chamada 
através do contêiner de injeção de dependência e é assim 
com todas as demais Factories. É importante ressaltar 


que estamos passando como parâmetro da nossa classe 
TipoUsuarioListarHandler o objeto do tipo 
ContainerInterface contido no parámetro $container . 


Lembre-se de que nossos Handlers estenderão a classe 
abstrata Handlerabstract que contém o método construtor 
e é exatamente nele que informamos que, ao 
construirmos um objeto de Handler, deverá ser passado 
como parâmetro um objeto do tipo containerInterface . 


y 


Nosso próximo passo é registrar o nosso Handler em 
nosso arquivo de configuração configProvider e é isso 
que faremos na próxima seção. 


Registrando o Handler TipoUsuarioListarHandler 


Como já fizemos com nossos serviços anteriormente, 
devemos registrar nossos Handlers também, caso 
contrário, o Zend Expressive não saberá que eles existem 
e quando chamarmos uma rota ele não conseguirá 
encontrar. Vamos registrá-lo para que isso não ocorra. 


7 


Para registrarmos é bem simples, abra o arquivo 
src/App/src/ConfigProvider.php € localize o método 
getDependencies() . Logo abaixo do registro 
Handler\TestDoctrineConnectionHandler::class que 
fizemos no capitulo 6, digite o código de registro a seguir: 


Handler\TipoUsuario\TipoUsuarioListarHandler::class => 
Handler\Factory\TipoUsuario\TipoUsuarioListarHandlerFacto 
ry::class 


É somente isso, esse pequeno trecho de código que você 
acabou de digitar já é responsável por realizar o registro 
do nosso Handler. 


Se estiver dessa maneira, parabéns, você está no 
caminho certo. Caso não esteja, reveja os passos com 
calma e tente novamente. 


Na próxima seção vamos continuar a criação dos nossos 
Handlers de tipos de usuários. 


12.2 Criando O Handler 
TipoUsuarioListarUmHandler 


Agora vamos criar o Handler que será responsável por 
listar apenas um registro de tipo de usuário. lsso será 
possível com o parâmetro id que vamos informar na 
URL. É por meio dele que vamos buscar no banco de 
dados o registro equivalente ao id informado. 


Em seu diretório src/App/src/Handler/TipoUsuario , crie 
uma classe chamada TipoUsuarioListarUmHandler , 
conforme mostra a imagem a seguir: 
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Figura 12.5: Criando o Handler TipoUsuarioListarUmHandler 


Após a criação da classe de Handler, vamos analisar o 
codigo completo dela a seguir e entender o que ela faz: 


<?php 
declare(strict_types=1) ; 
namespace App\Handler\TipoUsuario; 


use App\Handler\HandlerAbstract; 
use App\Service\TipoUsuarioService; 


use Psr\Http\Message\ResponselInterface; 

use Psr\Http\Message\ServerRequestinterface; 
use Psr\Http\Server\RequestHandleriInterface; 
use Zend\Diactoros\Response\JsonResponse; 


ff BX 
* Class TipoUsuarioListarUmHandler 
* @package App\Handler\TipoUsuario 
a 
class TipoUsuarioListarUmHandler extends HandlerAbstract 
implements RequestHandlerInterface 
{ 
JER 
* @param ServerRequestInterface $request 
* @return ResponseInterface 
E À 
public function handle(ServerRequestInterface 
$request): ResponseInterface 


{ 
$id = (int)$request->getAttribute('id'); 


$service = $this->container- 

>get (TipoUsuarioService::class); 
$resultwithDQL = $service->getOne($id); 
$resultwithoutDQL = $service->getOnewithDQL ($id) ; 


if (!empty(SresultwithDQL) && 
lempty($resultwithoutDQL)) { 
return new JsonResponse( [ 
'result with dql' => $resultwithDQL, 
'result without dql' => $resultwithoutDQL 
], 200); 


return new JsonResponse( [ 
'error' => true, 
'message' => 'Nenhum registro encontrado' 


], 404); 


Como vocé pode ver, a classe é bem semelhante a nossa 
classe de Handler TipoUsuarioListarHandler , e ela faz 
praticamente a mesma coisa, porém, aqui temos algumas 
diferencas dentro do nosso método 
handle(ServerRequestInterface $request) . 


O primeiro trecho a ser observado é o codigo $id = 
(int)$request->getAttribute('id') , que tem como 
responsabilidade recuperar o id que foi informado como 
parâmetro da URL, que vamos definir na rota mais à 
frente neste livro. 


Em seguida, o código transformará o valor do parâmetro 
obtido da URL em um número inteiro por meio do cast 

(int) e armazenar o valor na variável $id para que 
possamos utilizá-la. 


É importante informar que esse método pode ter algumas 
melhorias para garantir que o valor informado realmente é 
um número e um número inteiro. Isso pode ser feito por 
você mesmo como um simples exercício. 


Os próximos trechos de códigos a serem observados são 
$resultwithDQL = $service ->getOne($id) e 
$resultwithoutDQL = #£$service->getOnewithDQL($id) 
Perceba que estamos passando como parametro dos 
metodos a variavel $id e consequentemente estamos 
armazenando o resultado dos metodos em suas variaveis 
$resultwithDQL € $resultwithoutDQL , respectivamente. 


Temos uma condicáo com a qual verificamos se as 


variáveis contendo os resultados não são vazias. Caso 
não sejam vazias, retornamos o objeto JsonResponse 
contendo as informações, e informamos que o código de 
status da resposta é 200 , isto é, que é uma requisição 
que foi bem-sucedida e retornou resultados. Caso a 
condição não seja satisfeita, retornamos um objeto 

JsonResponse contendo como resposta duas chaves 
dentro do array: error , com o valor true ; € message , 
com o valor Nenhum registro encontrado . Como segundo 
parámetro da classe JsonResponse , temos o código de 
status 404 , que indica que nenhum registro foi 
encontrado. 


Agora que criamos nosso Handler 
TipoUsuarioListarUmHandler , vamos criar sua Factory na 
próxima seção. 


Criando a Factory 
TipoUsuarioListarUmHandlerFactory 


Esta Factory que vamos criar agora sera responsavel por 
retornar a instancia do nosso Handler 
TipoUsuarioListarUmHandler . Então, crie a Factory 
TipoUsuarioListarUmHandlerFactory dentro do nosso 
diretório src/App/src/Handler/Factory/TipoUsuario , 
conforme mostra a imagem a seguir: 
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Figura 12.6: Criando a Factory TipoUsuarioListarUmHandlerFactory 


Após a criação da Factory, vamos ver como é seu código 
completo a seguir: 


<?php 
declare(strict types=1); 
namespace App\Handler\Factory\TipoUsuario; 


use App\Handler\TipoUsuario\TipoUsuarioListarUmHandler ; 
use Interop\Container\ContainerInterface; 


pu 
* Class TipoUsuarioListarUmHandlerFactory 


* @package App\Handler\Factory\TipoUsuario 
E 
class TipoUsuarioListarUmHandlerFactory 
{ 
/** 
* @param ContainerInterface $container 
* @return TipoUsuarioListarUmHandler 
ef 
public function __invoke(ContainerInterface 
$container): TipoUsuarioListarUmHandler 
{ 
return new 
TipoUsuarioListarUmHandler($container); 


} 
} 
Assim como a nossa Factory 
TipoUsuarioListarHandlerFactory , a Nossa Factory 


TipoUsuarioListarUmHandlerFactory é bem simples e tem o 
objetivo de retornar uma instância da classe 
TipoUsuarioListarUmHandler , que poderemos utilizar por 
meio do nosso contêiner de injeção de dependência. Mas, 
para que isso seja possível, devemos registrar nosso 
Handler, assim como fizer anteriormente com os serviços 


e com o Handler TipoUsuarioListarHandler , e é 
exatamente isso que faremos na próxima seção. 


Registrando o Handler TipoUsuarioListarUmHandler 


Para registrarmos, abra O arquivo 
src/App/src/ConfigProvider.php e localize o método 
getDependencies() . Logo abaixo do registro 


Handler\TipoUsuario\TipoUsuarioListarHandler::class que 
fizemos anteriormente, coloque o código de registro a 
seguir: 


HandlerNTipoUsuarioNTipoUsuarioListarUmHandler::class => 
HandleriFactoryNTipoUsuarioNTipoUsuarioListarUmHandlerFac 
tory::class 


Com isso, nosso Handler foi devidamente registrado e ja 
poderá ser utilizado pela nossa aplicação. 


Finalizamos a criação de mais um Handler. Na próxima 
seção vamos criar o Handler TipoUsuarioCriarHandler que 
será responsável pela criação dos registros de tipos de 
usuário. 


12.3 Criando o Handler TipoUsuarioCriarHandler 


Este Handler será responsável por realizar a criação dos 
registros de tipos de usuários. Ele fará a inserção dos 
dados no banco de dados por meio do metodo post do 
HTTP que vamos definir no momento da criação das rotas 
da aplicação. 


Em seu diretório src/App/src/Handler/TipoUsuario , crie 
uma classe chamada TipousuarioCriarHandler , conforme 
mostra a imagem a seguir: 
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Figura 12.7: Criando o Handler TipoUsuarioCriarHandler 


Após a criacáo da classe, vamos analisar seu código 
completo e entender o que ela faz: 


<?php 
declare(strict_types=1); 
namespace App\Handler\TipoUsuario; 


use App\Handler\HandlerAbstract; 
use App\Service\TipoUsuarioService; 


use Psr\Http\Message\ResponselInterface; 

use Psr\Http\Message\ServerRequestinterface; 
use Psr\Http\Server\RequestHandleriInterface; 
use Zend\Diactoros\Response\JsonResponse; 
use Zend\Json\Json; 


PER 
* Class TipoUsuarioCriarHandler 
* @package App\Handler\TipoUsuario 
*/ 
Class TipoUsuarioCriarHandler extends HandlerAbstract 
implements RequestHandlerInterface 
{ 
Jax 
* @param ServerRequestInterface $request 
* @return ResponseInterface 
*/ 
public function handle(ServerRequestInterface 
$request): ResponseInterface 
{ 
$data = Json::decode($request ->getBody()- 
>getContents(), JSON OBJECT AS ARRAY); 


$service = $this->container- 
>get(TipoUsuarioService::class); 
$userType = $service->insert($data); 


return new JsonResponse( [ 
'data' => $userType 
], 200); 


} 


Como você pode ver, o código é bem simples e temos em 
nosso método handle(ServerRequestInterface $request) O 
código $data =  Json::decode($request->getBody()- 
>getContents(), JSON OBJECT AS ARRAY) . Ele é responsável 


por obter os dados que foram enviados por meio do corpo 
da requisição post em formato JSON, transformá-los em 

array e armazená-los na variável $data para que 
possamos utilizá-los. 


Em seguida, temos o código $userType = $service- 
>insert($data) , que é responsável por realizar a inserção 
dos dados por meio do método insert($data) do nosso 
serviço. Esse método recebe como parâmetro os dados 
obtidos da requisição, que foram convertidos em array e 
estão armazenados na variável $data . 


Por fim, temos o retorno do método. Estamos informando 
que os dados a serem exibidos como resposta serão os 
dados do tipo de usuário que acabou de ser criado. 


Na próxima seção vamos criar a Factory do nosso 
Handler. 


Criando a Factory TipoUsuarioCriarHandlerFactory 


Esta Factory será responsável por retornar a instância do 
nosso Handler TipoUsuarioCriarHandler . Então, crie a 
Factory TipoUsuarioCriarHandlerFactory dentro do nosso 
diretorio src/App/src/Handler/Factory/TipoUsuario 
conforme mostra a imagem a seguir: 
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Figura 12.8: Criando a Factory TipoUsuarioCriarHandlerFactory 


Após a criação da Factory, vamos ver como é seu código 
completo: 


<?php 
declare(strict_types=1); 
namespace App\Handler\Factory\TipoUsuario; 


use App\Handler\TipoUsuario\TipoUsuarioCriarHandler; 
use Interop\Container\ContainerInterface; 


pen 
* Class TipoUsuarioCriarHandlerFactory 


* @package App\Handler\Factory\TipoUsuario 
"E 
class TipoUsuarioCriarHandlerFactory 


{ 
per 
* @param ContainerInterface $container 
* @return TipoUsuarioCriarHandler 
ef 
public function __invoke(ContainerInterface 
$container): TipoUsuarioCriarHandler 


{ 


return new TipoUsuarioCriarHandler(Scontainer ); 


} 


Até aqui nenhum segredo, a Factory está retornando a 
instância do Handler TipoUsuarioCriarHandler para que 
possamos utilizar em nossa aplicação, assim como 
fizemos com as demais. 


Na próxima seção faremos o registro do nosso Handler 
TipoUsuarioCriarHandler para que o Zend Expressive o 
reconheça e possa utilizá-lo. 


Registrando o Handler TipoUsuarioCriarHandler 


Assim como fizemos anteriormente, vamos registrar o 


nosso Handler. Abra O arquivo 
src/App/src/ConfigProvider.php œe localize o método 
getDependencies() . Logo abaixo do registro 


HandlerNTipoUsuarioNTipoUsuarioListarUmHandler::class 
que fizemos anteriormente, coloque o código de registro a 
seguir: 


Handler\TipoUsuario\TipoUsuarioCriarHandler::class => 
Handler\Factory\TipoUsuario\TipoUsuar ioCriarHandlerFactor 


y::class 


Com isso, nosso Handler foi devidamente registrado e ja 
poderá ser utilizado pela nossa aplicação. 


Finalizamos a criação de mais um Handler. Na próxima 
seção vamos criar o Handler TipoUsuarioAlterarHandler 
que será responsável pela alteração de todos os dados de 
um determinado tipo de usuário. 


12.4 Criando O Handler 
TipoUsuarioAlterarHandler 


Nosso próximo passo é criar o Handler que fará a 
alteracáo dos dados de um determinado tipo de usuário. 
Isso será feito pelo id que será informado como 
parâmetro da requisição. Para esse caso, nós vamos 
utilizar o método put do HTTP. 


Em seu diretório src/App/src/Handler/Tipousuario , crie 
uma classe chamada TipoUsuarioAlterarHandler , 
conforme mostra a imagem a seguir: 
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Figura 12.9: Criando o Handler TipoUsuarioAlterarHandler 


Após a criação da classe, vamos analisar seu código 
completo a seguir e entender o que ela faz: 


<?php 

declare(strict types=1); 

namespace App\Handler\TipoUsuario; 
use App\Handler\HandlerAbstract; 


use App\Service\TipoUsuarioService; 
use Psr\Http\Message\ResponselInterface; 


use Psr\Http\Message\ServerRequestInterface; 
use Psr\Http\Server\RequestHandlerInterface; 
use Zend\Diactoros\Response\JsonResponse; 
use Zend\Json\Json; 


JER 
* Class TipoUsuarioAlterarHandler 
* @package App\Handler\TipoUsuario 
EA 
class TipoUsuarioAlterarHandler extends HandlerAbstract 
implements RequestHandlerInterface 
{ 
PRA 
* (param ServerRequestInterface $request 
* @return ResponseInterface 
A 
public function handle(ServerRequestInterface 
$request): ResponseInterface 
{ 
$data = Json: :decode($request ->getBody( ) - 
>getContents(), JSON OBJECT AS ARRAY); 
$data['id'] = (int)$request->getAttribute('id'); 


$service = $this->container- 
>get (TipoUsuarioService::class); 
$userType = $service->update($data); 


return new JsonResponse( [ 
'data' => $userType 
], 200); 


} 


O código dessa classe também é bastante simples e, 
como no Handler TipoUsuarioCriarHandler , temos o 
código $data =  Json::decode($request->getBody()- 
>getContents(),  JSON OBJECT AS ARRAY) , QUe possui 


exatamente a mesma função já explicada anteriormente. 


Em seguida, temos o código $data['id'] = (int)$request- 
>getattribute('id') , que obtém o id informado como 
parâmetro da requisição, converte o valor obtido em um 
número inteiro, e armazena o resultado através da criação 
da chave id dentro do array contido na variável $data . 
Esse campo estará disponível dentro do array e poderá 
ser utilizado pelo método update($data) do serviço de tipo 
de usuário. 


Temos também o código $userType = $service- 
>update($data) , que é responsável por realizar a alteração 
dos dados do tipo de usuário. Veja que estamos passando 
O array de dados contido na variável $data como 
parâmetro do método update($data) para que ele possa 
fazer a alteração dos dados corretamente. Por fim, ele 
armazena o resultado da alteração dos dados na variável 
$userType para que possamos utilizá-la no retorno do 
método. 


O retorno do método é bem semelhante ao do Handler 
TipoUsuarioCriarHandler , OU Seja, estamos retornando um 
objeto JSON contendo uma chave data , que contém o 
resultado da alteração feita anteriormente e que foi 
armazenado na variável $userType . 


Na próxima seção faremos a criação da Factory do 
Handler TipousuarioalterarHandler . 


Criando a Factory TipoUsuarioAlterarHandlerFactory 


Esta Factory será responsável por retornar a instância do 
nosso Handler TipoUsuarioAlterarHandler . Então, crie a 


Factory TipoUsuarioAlterarHandlerFactory dentro do 
nosso diretório  src/App/src/Handler/Factory/TipoUsuario 
conforme mostra a imagem a seguir: 


livro-zend-expressive 


bin 
conf g 
gata 
public 


SFC 


Ea = = 
Lh he 


Doctrine 





Figura 12.10: Criando a Factory TipoUsuarioAlterarHandlerFactory 


Após a criação da Factory, vamos ver como é seu código 
completo a seguir: 


<?php 
declare(strict types=1); 
namespace App\Handler\Factory\TipoUsuario; 


use App\Handler\TipoUsuario\TipoUsuarioAlterarHandler ; 
use Interop\Container\ContaineriInterface; 


jee 
* Class TipoUsuarioAlterarHandlerFactory 
* @package App\Handler\Factory\TipoUsuario 
ii 

class TipoUsuarioAlterarHandlerFactory 


{ 
jer 
* @param ContainerInterface $container 
* @return TipoUsuarioAlterarHandler 
“7 
public function __invoke(ContaineriInterface 
$container ): TipoUsuarioAlterarHandler 


{ 


return new TipoUsuarioAlterarHandler(Scontainer ); 


} 


Assim como as demais Factories dos nossos Handlers, 
esta também não possui nenhum segredo. Seu objetivo é 
retornar a instância do nosso Handler 
TipoUsuarioAlterarHandler para a nossa aplicação. 


Na próxima seção, vamos fazer o registro do nosso 
Handler para que o Zend Expressive o reconheça e possa 
ser utilizado pela nossa aplicação. 


Registrando o Handler TipoUsuarioAlterarHandler 


Assim como fizemos anteriormente, vamos registrar o 
nosso Handler, para registrarmos, abra o arquivo 
src/App/src/ConfigProvider.php e localize o método 
getDependencies() . Logo abaixo do registro 
Handler\TipoUsuario\TipoUsuarioCriarHandler::class Que 
fizemos anteriormente, coloque o código de registro a 
seguir: 


Handler\TipoUsuario\TipoUsuarioAlterarHandler::class => 
Handler\Factory\TipoUsuario\TipoUsuarioAlterarHandlerFact 
ory::class 


Com isso, nosso Handler foi devidamente registrado e ja 
poderá ser utilizado pela nossa aplicação. 


Finalizamos a criação de mais um Handler. Na próxima 
seção vamos criar o Handler TipoUsuarioDeletarHandler 
que será responsável pela exclusão de um determinado 
tipo de usuário através do id informado no parâmetro da 
requisição. 


12.5 Criando O Handler 
TipoUsuarioDeletarHandler 


Agora vamos criar o último Handler de tipos de usuário, 
que será responsável por realizar a exclusão de um 
determinado tipo de usuário. lsso será feito através do id 
que será informado como parámetro da requisicáo. Para 
esse caso, nós vamos utilizar o método pELETE do HTTP. 
Você verá isso quando formos definir as rotas da 
aplicação, não se preocupe. 


Em seu diretório src/App/src/Handler/Tipousuario , crie 
uma classe chamada TipoUsuarioDeletarHandler , 
conforme mostra a imagem a seguir: 





v Em livro-zend-expressive 


Ma Doctrine 
la Entity 
landler 
> EM Factory 
Y EM TipoUsuario 


E" 
o EM 
a i 


il Handler.php 


prt oe ee! 
i j ] || a} | 


Figura 12.11: Criando o Handler TipoUsuarioDeletarHandler 


Após a criação da classe, vamos analisar seu código 
completo a seguir e entender o que ela faz: 


<?php 
declare(strict types=1); 


namespace App\Handler\TipoUsuario; 


use App\Handler\HandlerAbstract; 

use App\Service\TipoUsuarioService; 

use Psr\Http\Message\ResponselInterface; 

use Psr\Http\Message\ServerRequestInterface; 
use Psr\Http\Server\RequestHandlerInterface; 
use Zend\Diactoros\Response\JsonResponse; 
use Zend\Json\Json; 


JER 
* Class TipoUsuarioDeletarHandler 
* @package App\Handler\TipoUsuario 
A 
class TipoUsuarioDeletarHandler extends HandlerAbstract 
implements RequestHandlerInterface 
{ 
PER 
* @param ServerRequestInterface $request 
* @return ResponseInterface 
ws 
public function handle(ServerRequestInterface 
$request): ResponseInterface 


{ 
$id = (int)$request->getAttribute('id'); 


$service = $this->container- 
>get (TipoUsuarioService::class);, 
$userTypeDeleted = $service->delete($id); 


return new JsonResponse( [ 
'data' => $userTypeDeleted 
], 200); 


} 


O código demonstrado anteriormente é bem semelhante 
aos anteriores. Como você pode ver, temos o código $id 
= (int)$request->getAttribute('id') que possui como 


responsabilidade obter o id informado como parâmetro 
da requisição. Estamos convertendo o valor obtido em 
inteiro e o armazenando na variável $id para ser 
utilizado posteriormente. 


Em seguida, temos o código $userTypeDeleted = $service- 
>delete($id) , que é responsável por deletar o registro 
através do id que foi passado como parâmetro do 
método delete($id) e estamos armazenando o registro 
deletado do banco de dados na variável 


$userTypeDeleted . 


Por fim, temos o retorno do método que exibe o resultado 
da exclusão do registro, que, no caso, é o resultado que 
está armazenado na variável $userTypeDeleted . 


Agora que finalizamos a criação do nosso último Handler 
de tipos de usuário, vamos criar sua Factory também e é 
isso que faremos na próxima seção. 


Criando a Factory TipoUsuarioDeletarHandlerFactory 


Esta Factory será responsável por retornar a instância do 
nosso Handler TipousuarioDeletarHandler . Então, crie a 
Factory TipoUsuarioDeletarHandlerFactory dentro do 
nosso diretório  src/App/src/Handler/Factory/TipoUsuario 
conforme mostra a imagem a seguir: 
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Figura 12.12: Criando a Factory TipoUsuarioDeletarHandlerFactory 


Após a criação da Factory, vamos ver como é seu código 
completo a seguir: 


<?php 
declare(strict types=1); 
namespace App\Handler\Factory\TipoUsuario; 


use App\Handler\TipoUsuario\TipoUsuarioDeletarHandler ; 
use Interop\Container\ContaineriInterface; 


f es 


* Class TipoUsuarioDeletarHandlerFactory 
* @package App\Handler\Factory\TipoUsuario 
ef 

class TipoUsuarioDeletarHandlerFactory 


{ 
yma 
* @param ContainerInterface $container 
* @return TipoUsuarioDeletarHandler 
"y 
public function | invoke(ContainerInterface 
$container): TipoUsuarioDeletarHandler 


{ 


return new TipoUsuar ioDeletarHandler ($container); 


} 


Assim como as demais Factories que criamos neste 
capitulo, essa não teria função diferente: ela possui a 
responsabilidade de retornar a instância do Handler 
TipoUsuarioDeletarHandler.. 


Vale lembrar que todas as Factories que criamos neste 
capítulo necessitam da passagem do parâmetro 
$container do tipo Interop\Container\ContainerInterface 
no momento da criação da instância. 


Esse parâmetro foi definido no construtor da classe 
HandlerAbstract e, consequentemente, todos os Handlers 
que herdaram essa classe possuem o método construtor 
que recebe como parâmetro O $container . 


Na próxima seção vamos fazer o registro do Handler para 
que o Zend Expressive possa reconhecê-lo e para que 
nossa aplicação possa utilizá-lo. 


Registrando o Handler TipoUsuarioDeletarHandler 


Assim como fizemos anteriormente, vamos registrar o 


nosso Handler. Abra O arquivo 
src/App/src/ConfigProvider.php e localize o método 
getDependencies() . Logo abaixo do registro 


Handler\TipoUsuario\TipoUsuarioAlterarHandler::class que 
fizemos anteriormente, coloque o código de registro a 
seguir: 


Handler\TipoUsuario\TipoUsuarioDeletarHandler::class => 
Handler\Factory\TipoUsuario\TipoUsuarioDeletarHandlerFact 
ory::class 


O código completo de seu método  getDependencies() 
deve ser parecido com o demonstrado a seguir: 


public function getDependencies() : array 
{ 
return [ 
'invokables' => [ 
Handler\PingHandler::class => 
Handler\PingHandler::class, 
l, 
'factories' => [ 
Handler\HomePageHandler::class => 
Handler\HomePageHandlerFactory::class, 
Handler\TestDoctrineConnectionHandler::class 
=> 
Handler\Factory\TestDoctrineConnectionHandlerFactory::cla 
SS, 


//Handlers de Tipos de Usuario 
Handler\TipoUsuario\TipoUsuarioListarHandler::class => 
Handler\Factory\TipoUsuario\TipoUsuarioListarHandlerFacto 


ry::class, 


Handler\TipoUsuario\TipoUsuarioListarUmHandler::class => 


Handler\Factory\TipoUsuario\TipoUsuarioListarUmHandlerFac 
tory::class, 


Handler\TipoUsuario\TipoUsuarioCriarHandler::class => 
Handler\Factory\TipoUsuario\TipoUsuar ioCriarHandlerFactor 
y::class, 


Handler\TipoUsuario\TipoUsuarioAlterarHandler::class => 
Handler\Factory\TipoUsuario\TipoUsuarioAlterarHandlerFact 
ory::class, 


Handler\TipoUsuario\TipoUsuarioDeletarHandler::class => 
Handler\Factory\TipoUsuario\TipoUsuarioDeletarHandlerFact 
ory::class, 


//Registrando Servicos 
Service\TipoUsuarioService::class => 
Service\Factory\TipoUsuarioServiceFactory::class, 
Service\USuarioService::class => 
Service\Factory\UsuarioServiceFactory::class, 
Service\MensagemService::class => 
Service\Factory\MensagemServiceFactory::class 


1, 
J; 
} 


Com isso, nosso Handler foi devidamente registrado e ja 
poderá ser utilizado pela nossa aplicação. Finalizamos a 
criação do ultimo Handler de tipo de usuário. 


Conclusão 


Chegamos ao fim de mais um capítulo, no qual definimos 
os Handlers de tipos de usuário, ou seja, os Handlers que 
farão a listagem, criação, exclusão e alteração dos 
registros. Também fizemos a criação das Factories dos 
nossos Handlers e realizamos também o registro de cada 


um dos Handlers que criamos. 


Em nosso próximo capítulo, daremos continuidade na 
criação de Handlers e vamos criar os Handlers de 
usuários, então siga em frente sem desanimar e vamos 
nessa! 


CaríruLo 13 
Criando e registrando Handlers de 
usuários 


No capítulo anterior, criamos os Handlers de tipos de 
usuário, sendo que cada Handler é responsável por uma 
determinada ação, como listar todos os registros, listar 
apenas um registro, criar um registro, alterar um registro e 
deletar um registro. 


Para os Handler de usuários não será diferente, faremos 
como no capítulo anterior e não terá segredos porque o 
processo de criação e registro é exatamente o mesmo. 
Nas próximas seções veremos cada Handler de usuário 
que criaremos para a nossa aplicação, onde serão 
explicados apenas os pontos mais importantes, pois já 
conhecemos o processo de criação. 


13.1 Criando o Handler UsuarioListarHandler 


Primeiramente, vamos criar o Handler que será 
responsável por listar os usuários cadastrados no banco 
de dados. Para isso, crie o diretório Usuario dentro de 
src/App/src/Handler e, em seguida, crie a classe 
UsuarioListarHandler dentro do diretório Usuario , 
conforme mostra a imagem a seguir: 
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Figura 13.1: Criando o Handler UsuarioListarHandler 


Vamos ver como é o código completo desse Handler a 
seguir: 


<?php 
declare(strict_types=1); 


namespace App\Handler\Usuario; 


use App\Handler\HandlerAbstract; 

use App\Service\UsuarioService; 

use Psr\Http\Message\ResponselInterface; 

use Psr\Http\Message\ServerRequestIinterface; 
use Psr\Http\Server\RequestHandlerInterface; 
use Zend\Diactoros\Response\JsonResponse; 


pr 
* Class UsuarioListarHandler 
* (package AppiHandlerXUsuario 
E 
class UsuarioListarHandler extends HandlerAbstract 
implements RequestHandlerInterface 
{ 
Je 
* @param ServerRequestInterface $request 
* @return ResponseInterface 
eS 
public function handle(ServerRequestInterface 
$request): ResponseInterface 
{ 
$service = $this->container- 
>get(UsuarioService::class); 
$resultwithDQL = $service->getAll(); 
$resultwithoutDQL = $service->getAl1WithDQL(); 


return new JsonResponse([ 
'result with dql' => $resultWithDQL, 
'result without dql' => $resultwithoutDQL 
], 200); 


} 


Como você pode ver, o código é bem semelhante ao da 
classe TipousuarioListarHandler . À única diferença é que 
a nossa classe UsuarioListarHandler realizará a listagem 


dos usuários, e não dos tipos de usuários existentes. Isso 
pode ser visto no código $service = $this->container- 
>get (UsuarioService::class) , em que estamos buscando 
em nosso contêiner de injeção de dependências o serviço 
de usuário, que será responsável, nesse caso, por listar 
os usuários cadastrados em nosso banco de dados. 


O retorno do método é exatamente o mesmo contido na 
classe  TipousuarioListarHandler , inclusive as chaves 
definidas para exibição dos resultados. A diferença é que 
nesse caso estaremos retornando os usuários. 


Agora que criamos nosso Handler para listar os usuários, 
na próxima seção vamos criar a Factory do nosso 
Handler. 


Criando a Factory UsuarioListarHandlerFactory 


Como você já sabe, as Factories são responsáveis por 
realizar a criação/instância de um objeto sem exibir a 
lógica para o código que realiza a chamada. Devemos 
criar a Factory porque nossos Handlers possuem uma 
dependência que é um objeto do tipo 
Interop\Container\ContainerInterface definido no 
construtor da nossa classe abstrata HandlerAbstract . 


Para criar a nossa Factory, crie o diretório usuario dentro 
do diretório src/App/src/Handler/Factory e, em seguida, a 
classe UsuarioListarHandlerFactory , conforme mostra a 
imagem a seguir: 
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Figura 13.2: Criando a Factory UsuarioListarHandlerFactory 


Após a criação da Factory, vamos ver como será seu 
código a seguir: 


<?php 
declare(strict types=1); 
namespace App\Handler\Factory\Usuario; 


use App\Handler\UsSuario\USuarioListarHandler ; 
use Interop\Container\ContainerInterface; 


/** 
* Class UsuarioListarHandlerFactory 
* (package App\Handler\Factory\Usuario 
"7 

class UsuarioListarHandlerFactory 


{ 
per 
* @param ContainerInterface $container 
* @return UsuarioListarHandler 
e 
public function __invoke(ContainerInterface 
$container): UsuarioListarHandler 


{ 


return new UsuarioListarHandler ($container); 


} 


Nenhuma novidade na criação dessa Factory. Lembre-se, 
a Factory deve apenas retornar a instância de uma classe 
que, nesse caso, é a instância da classe 
UsuarioListarHandler . 


Na próxima seção faremos o registro do nosso Handler 
em nosso arquivo de configuração, como fizemos no 
capítulo anterior. 


Registrando o Handler UsuarioListarHandler 


Para registrarmos é bem simples, abra o arquivo 
src/App/src/ConfigProvider.php €e localize o método 
getDependencies() . Logo abaixo do registro 

Handler\TipoUsuario\TipoUsuarioDeletarHandler::class que 

fizemos no capítulo anterior, coloque o código de registro 

a seguir: 


HandlerXUsuarioXUsuarioListarHandler::class => 


HandlerXFactoryXUsuarioXUsuarioListarHandlerFactory::clas 
S 


Na próxima seção vamos criar o Handler responsável por 
listar apenas um usuário através do id informado no 
parâmetro da URL. 


13.2 Criando o Handler UsuarioListarUmHandler 


Vamos criar o Handler que será responsável por realizar a 
listagem de apenas um usuário através do id que deverá 
ser informado como parâmetro da URL. Esse parâmetro 
será definido no momento em que criarmos as rotas da 
nossa aplicação. 


Crie a classe UsuarioListarHandler dentro do diretório 
src/App/src/Handler/Usuario , Conforme mostra a imagem 
a seguir: 
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Figura 13.3: Criando o Handler UsuarioListarUmHandler 


Após a criação da classe, vamos ver como é seu código 
completo a seguir: 


<?php 
declare(strict_types=1); 


namespace App\Handler\Usuario; 


use App\Handler\HandlerAbstract; 

use App\Service\UsuarioService; 

use Psr\Http\Message\ResponselInterface; 

use Psr\Http\Message\ServerRequestIinterface; 
use Psr\Http\Server\RequestHandlerInterface; 
use Zend\Diactoros\Response\JsonResponse; 


pr 
* Class UsuarioListarUmHandler 
* (package AppiHandlerXUsuario 
a 
Class UsuarioListarUmHandler extends HandlerAbstract 
implements RequestHandlerInterface 
{ 
Je 
* @param ServerRequestInterface $request 
* @return ResponseInterface 
el 
public function handle(ServerRequestInterface 
$request): ResponseInterface 


{ 
$id = (int)$request->getAttribute('id'); 


$service = $this->container- 
>get(UsuarioService::class); 

$resultwithDQL = $service->getOne($id); 

$resultwithoutDQL = $service->getOnewithDQL ($id) ; 


if (!empty(SresultwithDQL) && 
lempty($resultwithoutDQL)) { 
return new JsonResponse( [ 
'result with dql' => $resultWithDQL, 
'result without dql' => $resultwithoutDQL 
], 200); 


return new JsonResponse([ 

'error' => true, 

'message' => 'Nenhum registro encontrado' 
], 404); 


} 


Vocé deve estar se perguntando: eu ja vi esse codigo em 
algum lugar? Sim, você viu! Esse código é igual ao do 
Handler TipoUsuarioListarUmHandler , mudando apenas o 
serviço que será chamado do contêiner de injeção de 
dependência para que possamos utilizar adequadamente. 


O codigo $service = $this->container - 
>get (UsuarioService::class) demonstra exatamente o que 
foi descrito anteriormente. Essa é a única diferença deste 
código com relação ao código do Handler 
TipoUsuarioListarUmHandler ; OS demais códigos presentes 
no método não foram alterados e por isso não serão 
explicados novamente. 


Nosso próximo passo será criarmos a Factory do Handler 

UsuarioListarUmHandler para que possamos obter sua 
instância por meio do nosso contêiner de injeção de 
dependência. 


Criando a Factory UsuarioListarUmHandlerFactory 


Como já dito anteriormente, o único objetivo da Factory é 
retornar a instância de uma classe, e nesse caso faremos 
com o Handler UsuarioListarUmHandler . 


Crie a classe UsuarioListaruUmHandlerFactory dentro do 
diretório  src/App/src/Handler/Factory/Usuario conforme 
mostra a imagem a seguir: 
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Figura 13.4: Criando a Factory UsuarioListarUmHandlerFactory 


Após a criação da Factory, seu código completo pode ser 
visto a seguir: 


<?php 
declare(strict_types=1); 
namespace App\Handler\Factory\Usuario; 


use App\Handler\Usuario\USuarioListarUmHandler ; 
use Interop\Container\ContainerInterface; 


/** 
* Class UsuarioListarUmHandlerFactory 
* @package App\Handler\Factory\Usuario 
"7 

class UsuarioListarUmHandlerFactory 


{ 
/** 
* @param ContainerInterface $container 
* @return UsuarioListarUmHandler 
ho 
public function _ invoke(ContainerInterface 
$container): UsuarioListarUmHandler 


{ 


return new UsuarioListarUmHandler ($container); 


} 


Nenhuma novidade, não é mesmo? É bem parecida como 
qualquer outra Factory que criamos até o momento. 
Nesse caso, ela retorna uma instância do Handler 
UsuarioListarUmHandler . 


O próximo passo é registrarmos esse Handler no arquivo 
de configuração configProvider e é isso que faremos em 
nossa próxima seção. 


Registrando o Handler UsuarioListarUmHandler 


Para registrarmos, abra O arquivo 
src/App/src/ConfigProvider.php €e localize o método 
getDependencies() . Logo abaixo do registro 


HandlerNusuarioNUsuarioListarHandler::class que fizemos 
anteriormente, coloque o código de registro a seguir: 


Handler\Usuario\USuarioListarUmHandler::class => 
Handler\Factory\Usuario\UsuarioListarUmHandlerFactory::cl 


ass 


Pronto, mais um Handler registrado. Na próxima seção 
vamos criar o Handler responsável por criar um registro 
de usuário. 


13.3 Criando o Handler UsuarioCriarHandler 


Vamos criar o Handler que será responsável por criar um 
registro de usuário quando uma requisição post do HTTP 
for efetuada para a rota responsável. 


Crie a classe UsuarioCriarHandler dentro do diretório 
src/App/src/Handler/Usuario , conforme mostra a imagem 
a seguir: 
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Figura 13.5: Criando o Handler UsuarioCriarHandler 


Após a criação do Handler, vamos ver como é seu código 
completo a seguir: 


<?php 


declare(strict types=1); 


namespace App\Handler\Usuario; 


use App\Handler\HandlerAbstract; 

use App\Service\UsuarioService; 

use Psr\Http\Message\ResponselInterface; 

use Psr\Http\Message\ServerRequestinterface; 
use Psr\Http\Server\RequestHandlerInterface; 
use Zend\Diactoros\Response\JsonResponse; 
use Zend\Json\Json; 


PER 
* Class UsuarioCriarHandler 
* (package AppiHandlerXUsuario 
*/ 
class UsuarioCriarHandler extends HandlerAbstract 
implements RequestHandlerInterface 
{ 
faz 
* @param ServerRequestInterface $request 
* @return ResponseInterface 
27 
public function handle(ServerRequestInterface 
$request): ResponseInterface 
{ 
$data = Json: :decode($request ->getBody( ) - 
>getContents(), JSON OBJECT AS ARRAY); 


$service = $this->container- 
>get (UsuarioService::class); 
$user = $service->insert($data); 


return new JsonResponse( [ 
'data' => $user 
], 200); 


Esse código também é bem semelhante ao do Handler 
TipoUsuarioCriarHandler . Note que a diferença é o código 
$service = $this->container->get(UsuarioService::class) , 
responsável por obter o serviço de usuario por meio do 
contéiner de injeção de dependência, e armazenar na 
variável $service . 


Isso é feito para que posteriormente possamos chamar o 
método insert($data) , que passa como parámetro o 
array de dados obtidos através da requisição. 


7 


Nosso próximo passo é criar a Factory do Handler 
UsuarioCriarHandler . 


Criando a Factory UsuarioCriarHandlerFactory 


Essa Factory sera responsavel por retornar a instancia da 
classe UsuarioCriarHandler . Crie a classe 
UsuarioCriarHandlerFactory dentro do diretório 
src/App/src/Handler/Factory/Usuario conforme mostra a 
imagem a seguir: 
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Figura 13.6: Criando a Factory UsuarioCriarHandlerFactory 


y 


A seguir, vamos ver como é o código completo dessa 
Factory: 


<?php 
declare(strict_types=1); 
namespace App\Handler\Factory\Usuario; 


use App\Handler\Usuario\USuarioCriarHandler; 
use Interop\Container\ContainerInterface; 


/** 
* Class UsuarioCriarHandlerFactory 
* (package App\Handler\Factory\Usuario 
"7 

class UsuarioCriarHandlerFactory 


{ 
jer 
* @param ContainerInterface $container 
* @return UsuarioCriarHandler 
a 
public function _ invoke(ContainerInterface 
$container): UsuarioCriarHandler 


{ 


return new UsuarioCriarHandler($container); 


} 


O código não possui nenhum segredo, essa Factory 
retorna a instância da classe UsuarioCriarHandler e nada 
mais. 


Na próxima seção vamos realizar o registro desse Handler 
para que possamos utilizá-lo futuramente quando 
criarmos e testarmos as rotas da aplicação. 


Registrando o Handler UsuarioCriarHandler 


Para registrarmos, abra O arquivo 
src/App/src/ConfigProvider.php € localize o método 
getDependencies() . Logo abaixo do registro 
Handler NUsuar iolUsuarioListarUmHandler::class que 


fizemos anteriormente, coloque o código de registro a 
seguir: 


Handler \Usuario\UsuarioCriarHandler::class => 
Handler \Factory\Usuario\UsuarioCriarHandlerFactory::class 


Pronto, mais um Handler registrado e pronto para ser 
utilizado. Na próxima seção vamos criar o Handler 
responsável por realizar a alteração dos dados de um 
registro de usuário. 


13.4 Criando o Handler UsuarioAlterarHandler 


Esse Handler será responsável por realizar a alteração 
dos dados de um determinado usuário. Primeiramente, 
crie a classe UsuarioalterarHandler dentro do diretório 
src/App/src/Handler/Usuario , conforme mostra a imagem 
a seguir: 


¥ Em livro-zend-expressive 


| Doctrine 


= 


E Factory 





Figura 13.7: Criando o Handler UsuarioAlterarHandler 


Após a criação da classe, vamos ver como será seu 
código completo a seguir: 


<?php 
declare(strict types=1); 


namespace App\Handler\Usuario; 


use App\Handler\HandlerAbstract; 

use App\Service\UsuarioService; 

use Psr\Http\Message\ResponselInterface; 

use Psr\Http\Message\ServerRequestIinterface; 
use Psr\Http\Server\RequestHandlerInterface; 
use Zend\Diactoros\Response\JsonResponse; 
use Zend\Json\Json; 


AER 
* Class UsuarioAlterarHandler 
* (package AppiHandlerXUsuario 
rd 
class UsuarioAlterarHandler extends HandlerAbstract 
implements RequestHandlerInterface 
{ 
fr 
* @param ServerRequestInterface $request 
* @return ResponseInterface 
RA 
public function handle(ServerRequestInterface 
$request): ResponseInterface 
{ 
$data = Json: :decode($request ->getBody()- 
>getContents(), JSON OBJECT AS ARRAY); 
$data['id'] = (int)$request->getAttribute('id'); 


$service = $this->container - 
>get (UsuarioService::class); 
$user = $service->update($data); 


return new JsonResponse( [ 
'data' => $user 
], 200); 


Como você pode ver, esse código também é bem 
semelhante ao do Handler TipoUsuarioAlterarHandler € 
temos apenas algumas diferenças. 


y 


A primeira é o código $service = $this->container- 
>get(UsuarioService::class) , responsável por armazenar 
na variável $service O serviço de usuário obtido do 
contêiner de injeção de dependência. 


Em seguida, temos o código $user = $service- 
>update($data) , responsável por realizar a alteração dos 
dados e armazenar o resultado da alteração na variável 
$user . 


Isso é feito para que possamos utilizá-la posteriormente 
no retorno do método, para que os dados possam ser 
enviados como resposta da requisição. 


O próximo passo é criarmos a Factory do Handler 
UsuarioAlterarHandler . 


Criando a Factory UsuarioAlterarHandlerFactory 


O objetivo dessa Factory e retornar a instancia da classe 
UsuarioAlterarHandler para que a aplicação possa 
realizar a utilização do Handler corretamente. 


Crie a classe UsuarioAlterarHandlerFactory dentro do 
diretório  src/App/src/Handler/Factory/Usuario , conforme 
mostra a imagem a seguir: 
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Figura 13.8: Criando a Factory UsuarioAlterarHandlerFactory 
Após a criação da Factory, vamos ver seu código a seguir: 
<?php 
declare(strict types=1); 
namespace App\Handler\Factory\Usuario; 


use App\Handler\Usuario\USuarioAlterarHandler ; 
use Interop\Container\ContainerInterface; 


sal 
* Class UsuarioAlterarHandlerFactory 


* @package App\Handler\Factory\USuario 
“yr 
class UsuarioAlterarHandlerFactory 


{ 
per 
* @param ContainerInterface $container 
* @return UsuarioAlterarHandler 
ef 
public function __invoke(ContainerInterface 
$container): UsuarioAlterarHandler 


{ 


return new UsuarioAlterarHandler($container ); 


} 


Como dito anteriormente essa Factory possui a 
responsabilidade de retornar a instância da classe 
UsuarioAlterarHandler , apenas isso e nada mais. 


O próximo passo é registrar o Handler para que nossa 
aplicação possa utilizá-lo corretamente. 


Registrando o Handler UsuarioAlterarHandler 


Para registrarmos, abra O arquivo 
src/App/src/ConfigProvider.php € localize o método 
getDependencies() . Logo abaixo do registro 


Handler\Usuario\UsuarioCriarHandler::class que fizemos 
anteriormente, coloque o código de registro a seguir: 


Handler \Usuario\UsuarioAlterarHandler::class => 
Handler \Factory\Usuario\UsuarioAlterarHandlerFactory::cla 
SS 


Após o registro desse Handler, podemos seguir em frente 
rumo ao ultimo Handler de usuário, que será responsável 


por realizar a exclusão de um determinado registro de 
usuário. 


13.5 Criando o Handler UsuarioDeletarHandler 


Esse Handler possui a responsabilidade de excluir um 
determinado registro de usuário do banco de dados 
através do id do usuário que deverá ser informado no 
parâmetro da URL. 


Crie a classe UsuarioDeletarHandler dentro do diretório 
src/App/src/Handler/Usuario , conforme mostra a imagem 
a seguir: 
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Figura 13.9: Criando o Handler UsuarioDeletarHandler 


Após a criação da classe, vamos ver como é seu código 
completo: 


<?php 





declare(strict types=1); 
namespace App\Handler\Usuario; 


use App\Handler\HandlerAbstract; 

use App\Service\UsuarioService; 

use Psr\Http\Message\ResponselInterface; 

use Psr\Http\Message\ServerRequestIinterface; 
use Psr\Http\Server\RequestHandlerInterface; 
use Zend\Diactoros\Response\JsonResponse; 


jf ** 
* Class UsuarioDeletarHandler 
* (package AppiHandlerXUsuario 
*/ 
Class UsuarioDeletarHandler extends HandlerAbstract 
implements RequestHandlerInterface 
{ 
Jes 
* @param ServerRequestInterface $request 
* @return ResponseInterface 
a É 
public function handle(ServerRequestInterface 
$request): ResponseInterface 
{ 
$id = (int)$request->getAttribute('id'); 


$service = $this->container- 
>get (UsuarioService::class); 
$userDeleted = $service->delete($id); 


return new JsonResponse( [ 
'data' => $userDeleted 
], 200); 


Novamente, o código é bem semelhante ao do Handler 
TipoUsuarioDeletarHandler e ha apenas pequenas 
diferenças. 


y 


A primeira é o código  $service = $this->container- 
>get(UsuarioService::class) , Que armazena na variável 
$service O servico de usuário obtido por meio do 
contêiner de injeção de dependência. 


A segunda diferença é o código $userDeleted = $service- 
>delete($id) que é responsável por deletar o usuário e 
armazenar na variável  $userDeleted O resultado da 
exclusão, que no caso é o usuário que foi excluído. O 
resultado é armazenado porque posteriormente vamos 
enviar esses dados como resposta no retorno do método, 


como você pode ver no código de retorno do método. 


y 


Por fim, nosso próximo passo é criar a Factory desse 
Handler e é isso que faremos na próxima seção. 


Criando a Factory UsuarioDeletarHandlerFactory 


Agora pergunto: qual é o objetivo dessa Factory? Se vocé 


está pensando que é retornar a instáncia da classe 
UsuarioDeletarHandler , Você acertou. 


Crie a classe  UsuarioDeletarHandlerFactory dentro do 
diretório src/App/src/Handler/Factory/Usuario , conforme 
mostra a imagem a seguir: 
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Figura 13.10: Criando a Factory UsuarioDeletarHandlerFactory 


Com a criação da Factory, vamos ver seu código 
completo a seguir: 


<?php 
declare(strict_types=1); 
namespace App\Handler\Factory\Usuario; 


use App\Handler\Usuario\UsuarioDeletarHandler; 


use Interop\Container\ContainerInterface; 


/** 
* Class UsuarioDeletarHandlerFactory 
* @package App\Handler\Factory\Usuario 
a é 

class UsuarioDeletarHandlerFactory 


{ 
fe 
* @param ContainerInterface $container 
* @return UsuarioDeletarHandler 
à 
public function _ invoke(ContainerInterface 
$container): UsuarioDeletarHandler 


{ 


return new UsuarioDeletarHandler($container ); 


} 


O código dessa Factory é como os demais, não possui 
segredo nenhum. Ela possui apenas uma 
responsabilidade: criar a instância da classe 
UsuarioDeletarHandler e retorná-la para que a aplicação 
possa utilizá-la. 


Por último, falta registramos esse Handler para que 
possamos utilizá-lo corretamente quando formos definir as 
rotas da aplicação. 


Registrando o Handler UsuarioDeletarHandler 


Por fim, vamos registrar o Handler UsuarioDeletarHandler , 
e como você já está bem acostumado, é bem simples 
fazer esse processo. Abra O arquivo 
src/App/src/ConfigProvider.php œe localize o método 
getDependencies() . Logo abaixo do registro 


Handler iUsuar iolUsuarioAlterarHandler::class que 
fizemos anteriormente, coloque o código de registro a 
seguir: 


Handler\Usuario\USuarioDeletarHandler::class => 
Handler\Factory\Usuario\UsuarioDeletarHandlerFactory::cla 
SS 


Mais um Handler esta devidamente registrado e pronto 
para ser utilizado pela nossa aplicação, e com isso 
chegamos ao final de mais um capitulo. 


Conclusao 


Vimos neste capitulo como criar o conjunto de Handlers 
de usuários, que serão responsáveis por listar, alterar, 
deletar e criar usuários. Não vimos nada de novo nesse 
processo, e, como você pôde ver, é um processo bem 
semelhante que fizemos no capítulo 12 com os Handlers 
de tipos de usuários. 


No próximo capítulo, faremos a criação do conjunto de 
Handlers que serão responsáveis pelos registros de 
mensagens dos usuários, como: listar, criar, alterar e 
deletar. Então, siga em frente e vamos nessa. 


CaríruLo 14 
Criando e registrando Handlers de 
Mensagens 


Neste capítulo, faremos a criação da sequência de 
Handlers que serão responsáveis pela troca de 
mensagens entre os usuários. Essa troca de mensagens 
não será em real-time (tempo real), mas sim inserida no 
banco de dados para que o usuário possa recuperar a 
mensagem e respondê-la. 


Assim como os demais Handlers que criamos nos 
capítulos anteriores, esses também não serão tão 
diferentes, pois a estrutura será basicamente a mesma, 
portanto, vamos nos debruçar apenas sobre as 
novidades. 


14.1 Criando o Handler MensagemListarHandler 


Vamos criar o Handler que será responsável por listar as 
mensagens cadastradas no banco de dados. Para isso, 
crie o diretório Mensagem dentro de src/App/src/Handler €, 
em seguida, crie a classe MensagemListarHandler dentro 
do diretório mensagem , conforme mostra a imagem a 
seguir: 
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Figura 14.1: Criando o Handler MensagemListarHandler 


Vamos ver como é o código completo desse Handler a 
seguir: 


<?php 
declare(strict types=1); 
namespace App\Handler\Mensagem; 


use App\Handler\HandlerAbstract; 
use App\Service\MensagemService; 


use Psr\Http\Message\ResponselInterface; 

use Psr\Http\Message\ServerRequestinterface; 
use Psr\Http\Server\RequestHandlerInterface; 
use Zend\Diactoros\Response\JsonResponse; 


JER 
* Class MensagemListarHandler 
* @package App\Handler\Mensagem 
A 
class MensagemListarHandler extends HandlerAbstract 
implements RequestHandlerInterface 
{ 
PRA 
* (param ServerRequestInterface $request 
* @return ResponseInterface 
e 
public function handle(ServerRequestInterface 
$request): ResponseInterface 
{ 
$service = $this->container- 
>get (MensagemService::class); 
$resultwithDQL = $service->getAll(); 
$resultwithoutDQL = $service->getAllwithDQL(); 


return new JsonResponse( [ 
'result with dql' => $resultWithDQL, 
'result without dql' => $resultwithoutDQL 
], 200); 


} 


Como você pode ver no código do Handler, é exatamente 
a mesma estrutura de outros Hadnlers de listagem de 
registros presente nos capítulos anteriores. Inclusive, é 


exatamente a mesma quantidade de linhas. 


A unica diferença presente é o código $service = $this- 


y 


>container ->get (MensagemService::class) que e 
responsável por armazenar na variável gservice O Nosso 
serviço de mensagens que criamos no capítulo 11. 


O restante do código é bem simples e não foi alterado e 
por esse motivo não será explicado pois você já sabe 
exatamente o que ele faz, certo? Certo! 


Criando a Factory MensagemListarHandlerFactory 


O objetivo dessa Factory será retornar uma instância da 
Classe MensagemListarHandler . Para isso, crie o diretório 
Mensagem dentro do diretório src/App/src/Handler/Factory 
e, em seguida, crie a classe MensagemListarHandlerFactory 
dentro do diretório src/App/src/Handler/Factory/Mensagem , 
conforme mostra a imagem a seguir: 
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Figura 14.2: Criando a Factory MensagemListarHandlerFactory 


A seguir vamos ver como é o código completo dessa 
Factory: 


<?php 
declare(strict types=1); 
namespace App\Handler\Factory\Mensagem; 


use App\Handler\Mensagem\MensagemListarHandler ; 
use Interop\Container\ContainerInterface; 


pen 
* Class MensagemListarHandlerFactory 


* @package App\Handler\Factory\Mensagem 
"p 
class MensagemListarHandlerFactory 


{ 
per 
* @param ContainerInterface $container 
* @return MensagemListarHandler 
ef 
public function __invoke(ContainerInterface 
$container): MensagemListarHandler 


{ 


return new MensagemListarHandler($container ); 


} 


Como dito anteriormente, essa Factory possui o objetivo 
de retornar apenas a instância da classe 
MensagemListarHandler . E simples assim. 


Nosso próximo passo é registrar o Handler para que a 
nossa aplicação saiba de sua existência para ser utilizado 
quando definirmos as rotas. 


Registrando o Handler MensagemListarHandler 


Como você já sabe, para registrarmos basta abrir o 
arquivo  src/App/src/ConfigProvider.php e localizar o 
método getDependencies() . Logo abaixo do registro 

Handler\Usuario\UsuarioDeletarHandler::class que 
fizemos no capitulo anterior, digite o código de registro a 
seguir: 


Handler \Mensagem\MensagemListarHandler::class => 
Handler\Factory\Mensagem\MensagemListarHandlerFactory: :cl 
ass 


Na próxima seção vamos criar o Handler responsável por 
listar apenas uma mensagem através do id informado no 
parâmetro da URL. 


14.2 Criando O Handler 
MensagemListarUmaHandler 


Esse Handler sera responsavel por listar apenas uma 
mensagem atraves do id da mensagem que devera ser 
informado na URL. 


Para isso, crie a classe MensagemListarUmaHandler dentro 
do diretório src/App/src/Handler/Mensagem , conforme 
mostra a imagem a seguir: 
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Figura 14.3: Criando o Handler MensagemListarUmaHandler 


Após a criação do Handler, vamos ver como sera seu 
código completo a seguir: 


<?php 
declare(strict_types=1) ; 
namespace App\Handler\Mensagem; 


use App\Handler\HandlerAbstract; 
use App\Service\MensagemService; 


use Psr\Http\Message\ResponselInterface; 

use Psr\Http\Message\ServerRequestinterface; 
use Psr\Http\Server\RequestHandlerInterface; 
use Zend\Diactoros\Response\JsonResponse; 


JER 
* Class MensagemListarUmaHandler 
* @package App\Handler\Mensagem 
*/ 
class MensagemListarUmaHandler extends HandlerAbstract 
implements RequestHandlerInterface 
{ 
F fls 
* @param ServerRequestInterface $request 
* @return ResponseInterface 
*/ 
public function handle(ServerRequestInterface 
$request): ResponseInterface 


{ 
$id = (int)$request->getAttribute('id'); 


$service = $this->container- 
>get(MensagemService::class); 

$resultwithDQL = $service->getOne($id); 

$resultwithoutDQL = $service->getOnewithDQL ($id) ; 


if (!empty(SresultwithDQL) && 
lempty($resultwithoutDQL)) { 
return new JsonResponse( [ 
'result with dql' => $resultWithDQL, 
'result without dql' => $resultwithoutDQL 
], 200); 


return new JsonResponse( [ 
'error' => true, 
'message' => 'Nenhum registro encontrado' 


], 404); 


Como vocé pode ver, o código é exatamente o mesmo do 
Handler UsuarioListarUmHandler , a unica diferença é o 
código $service = $this->container - 
>get(MensagemService::class) , que é responsável por 
armazenar na variável $service O servico de mensagens 


para que posteriormente possa ser utilizado. 


O código é exatamente o mesmo, inclusive a quantidade 
de linhas do código anterior é igual ao do Handler 
UsuarioListarUmHandler . 


Sem nenhum segredo, nosso próximo passo é criarmos a 
Factory desse Handler. 


Criando a Factory 
MensagemListarUmaHandlerFactory 


O objetivo dessa Factory e retornar uma instancia da 
Classe MensagemListarUmaHandler e nada mais. 


Para isso, crie a classe MensagemListarUmaHandlerFactory 
dentro do diretório src/App/src/Handler/Factory/Mensagem , 
conforme mostra a imagem a seguir: 
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Figura 14.4: Criando a Factory MensagemListarUmaHandlerFactory 


Após a criacáo da Factory, vamos ver como é seu código 
completo a seguir: 


<?php 
declare(strict_types=1); 
namespace App\Handler\Factory\Mensagem; 


use App\Handler\Mensagem\MensagemListarUmaHandler ; 
use Interop\Container\ContainerInterface; 


JEK 
* Class MensagemListarUmaHandlerFactory 


* @package App\Handler\Factory\Mensagem 
"p 
class MensagemListarUmaHandlerFactory 


{ 
per 
* @param ContainerInterface $container 
* (return MensagemListarUmaHandler 
=F 
public function _ invoke(ContainerInterface 
$container): MensagemListarUmaHandler 


{ 


return new MensagemListarUmaHandler ($container); 


} 


Como você pode ver no código, essa Factory não possui 


nada demais, não é mesmo? Seu objetivo é apenas 
retornar a instância da classe MensagemListarUmaHandler . 


Nosso próximo passo é registrarmos nosso Handler no 
arquivo de configuração. 


Registrando o Handler MensagemListarUmaHandler 


Para registrarmos, basta abrir O arquivo 
src/App/src/ConfigProvider.php e localizar o método 
getDependencies() . Logo abaixo do registro 
Handler iMensagemiMensagemL istarHandler::class que 


fizemos anteriormente, digite o código de registro a seguir: 


HandleriMensagemiMensagemListarUmaHandler::class => 
Handler\Factory\Mensagem\MensagemListarUmaHandlerFactory: 
¿Class 


Na próxima secáo vamos criar o Handler responsável por 
criar um registro de mensagem. 


14.3 Criando o Handler MensagemCriarHandler 


Este Handler será responsável por inserir as mensagens 
no banco de dados, e será bem semelhante aos Handler 
TipoUsuarioCriarHandler € UsuarioCriarHandler . 


Primeiramente, crie a classe MensagemCriarHandler dentro 
do diretório src/App/src/Handler/Mensagem , conforme 
mostra a imagem a seguir: 
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Figura 14.5: Criando o Handler MensagemCriarHandler 


Após a criação da classe, vamos ver como é o código 
completo dela a seguir: 


<?php 
declare(strict types=1); 
namespace App\Handler\Mensagem; 


use App\Handler\HandlerAbstract; 

use App\Service\MensagemService; 

use Psr\Http\Message\ResponselInterface; 

use Psr\Http\Message\ServerRequestIinterface; 
use Psr\Http\Server\RequestHandlerInterface; 
use Zend\Diactoros\Response\JsonResponse; 
use Zend\Json\Json; 


fre 
* Class MensagemCriarHandler 
* @package App\Handler\Mensagem 
rd 
class MensagemCriarHandler extends HandlerAbstract 
implements RequestHandlerInterface 
{ 
Pod 
* @param ServerRequestInterface $request 
* @return ResponseInterface 
*/ 
public function handle(ServerRequestInterface 
$request): ResponseInterface 
{ 
$data = Json: :decode($request ->getBody( ) - 
>getContents(), JSON OBJECT AS ARRAY); 


$service = $this->container- 
>get (MensagemService::class); 
$message = $service->insert($data); 


return new JsonResponse( [ 
'data' => $message 
], 200); 


} 


O código também é bem simples e não possui segredo 
nenhum. Há apenas três diferenças sutis. A primeira é o 
código $service = $this->container - 
>get (MensagemService::class) , que armazena na variável 

$service O Serviço de mensagens obtido através do 
contêiner de injeção de dependências. 


A segunda está no código $message = $service- 
>insert($data) , que armazena na variável $message O 
resultado da inserção da mensagem no banco de dados, 
retornando a mensagem inserida propriamente dita. 


A terceira diferença está no retorno do método, pois nele 
passamos a variável $message que contém o resultado da 
inserção para ser enviado para o cliente. 


Nosso próximo passo é criarmos a Factory desse nosso 
Handler. 


Criando a Factory MensagemCriarHandlerFactory 


O objetivo dessa Factory será retornar a instância da 
classe  MensagemCriarHandler , para isso, crie a classe 

MensagemCriarHandlerFactory dentro do diretório 
src/App/src/Handler/Factory/Mensagem conforme mostra a 
imagem a seguir: 
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Figura 14.6: Criando a Factory MensagemCriarHandlerFactory 


Após a criação da Factory, vamos ver como é o código 
completo dela a seguir: 


<?php 
declare(strict types=1); 
namespace App\Handler\Factory\Mensagem; 


use App\Handler\Mensagem\MensagemCriarHandler; 
use InteropiContainerAContainerInterface; 


qem 
* Class MensagemCriarHandlerFactory 


* @package App\Handler\Factory\Mensagem 
ai 
class MensagemCriarHandlerFactory 


{ 
per 
* @param ContainerInterface $container 
* (return MensagemCriarHandler 
ef 
public function __invoke(ContainerInterface 
$container): MensagemCriarHandler 


{ 


return new MensagemCriarHandler($container ); 


} 


Como você pode notar, o código da Factory não possui 
nenhum segredo e retorna a instância da classe 
MensagemCriarHandler . 


O próximo passo é registrarmos o Handler no arquivo de 
configuração. 


Registrando o Handler MensagemCriarHandler 


Para registrarmos basta abrir O arquivo 
src/App/src/ConfigProvider.php e localizar o método 
getDependencies() . Logo abaixo do registro 
HandleriMensagemiMensagemListarUmaHandler::class que 
fizemos anteriormente, digite o código de registro a seguir: 


Handler \Mensagem\MensagemCriarHandler::class => 
Handler \Factory\Mensagem\MensagemCriarHandlerFactory::cla 
SS 


Simples assim! Na próxima seção vamos criar o Handler 
responsável por realizar a alteração dos dados de um 


determinado registro de mensagem. 


14.4 Criando O Handler 
MensagemaAlterarHandler 


O objetivo desse Handler será realizar a alteração dos 
dados de um determinado registro de mensagem através 
do id que deverá ser informado como parâmetro da URL 
da rota. 


Crie a classe MensagemAlterarHandler dentro do diretório 
src/App/src/Handler/Mensagem conforme mostra a imagem 
a seguir: 
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Figura 14.7: Criando o Handler MensagemAlterarHandler 


Após a criação da classe, vamos ver como é o código 
completo dela a seguir: 


<?php 

declare(strict types=1); 
namespace App\Handler\Mensagem; 
use App\Handler\HandlerAbstract; 


use App\Service\MensagemService; 
use Psr\Http\Message\ResponselInterface; 


use Psr\Http\Message\ServerRequestinterface; 
use Psr\Http\Server\RequestHandlerInterface; 
use Zend\Diactoros\Response\JsonResponse; 
use Zend\Json\Json; 


JER 
* Class UsuarioAlterarHandler 
* (package App\Handler\Usuario 
a 
Class MensagemAlterarHandler extends HandlerAbstract 
implements RequestHandlerInterface 
{ 
paz 
* @param ServerRequestInterface $request 
* @return ResponseInterface 
E 
public function handle(ServerRequestInterface 
$request): ResponseInterface 
{ 
$data = Json::decode($request ->getBody( ) - 
>getContents(), JSON OBJECT AS ARRAY); 
$data['id'] = (int)$request->getAttribute('id'); 


$service = $this->container- 
>get (MensagemService: :class) ; 
$message = $service->update($data); 


return new JsonResponse( [ 
'data' => $message 
], 200); 


} 


O código também é bem semelhante com o que já vimos 
nos capítulos anteriores. Esse método possui três 
diferenças sutis e a primeira delas é o código $service = 
$this->container ->get (MensagemService: :class) que 


armazena na variável $service O serviço de mensagens. 


A segunda é o código $message = $service- 
>update($data) , que armazena na variável $message O 
resultado da alteração dos dados. 


E a terceira diferença está no retorno do método, no qual 
passamos para a chave data o resultado contido na 
variável $message , para ser enviado como resposta para o 
cliente. 


São apenas essas diferenças, o restante do código 
permanece o mesmo e sem alterações. O próximo passo 
é criar a Factory do nosso Handler. 


Criando a Factory MensagemAlterarHandlerFactory 


O objetivo dessa Factory será retornar uma instáncia da 
classe MensagemalterarHandler , para isso, crie a classe 

MensagemalterarHandlerFactory dentro do diretório 
src/App/src/Handler/Factory/Mensagem conforme mostra a 
imagem a seguir: 
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Figura 14.8: Criando a Factory MensagemAlterarHandlerFactory 


Após a criação da Factory, vamos ver o código completo 
dela a seguir: 


<?php 
declare(strict types=1); 
namespace App\Handler\Factory\Mensagem; 


use App\Handler\Mensagem\MensagemAlterarHandler ; 
use Interop\Container\ContaineriInterface; 


es 
* Class MensagemAlterarHandlerFactory 
* @package App\Handler\Factory\Mensagem 


e 
class MensagemAlterarHandlerFactory 


{ 
je 
* @param ContainerInterface $container 
* @return MensagemAlterarHandler 
E 
public function __invoke(ContainerInterface 
$container): MensagemAlterarHandler 


{ 


return new MensagemAlterarHandler(Scontainer); 


O código da Factory é simples e faz exatamente o que é 
esperado: retorna uma | instância da classe 
MensagemAlterarHandler . 


O próximo passo é registrarmos o Handler como temos 
feito até o momento. 


Registrando o Handler MensagemaAlterarHandler 


Para registrarmos, basta abrir O arquivo 
src/App/src/ConfigProvider.php e localizar o método 
getDependencies() . Logo abaixo do registro 
Handler \Mensagem\MensagemCriarHandler::class que 


fizemos anteriormente, digite o código de registro a seguir: 


Handler \Mensagem\MensagemAlterarHandler::class => 
Handler \Factory\Mensagem\MensagemAlterarHandlerFactory::c 
lass 


Na próxima seção vamos criar o Handler responsável por 
realizar a exclusão de um determinado registro de 
mensagem. 


14.5 Criando O Handler 
MensagemDeletarHandler 


O objetivo desse Handler é realizar a exclusão de um 
determinado registro de mensagem por meio do id 
informado como parâmetro da URL. 


Crie a classe MensagemDeletarHandler dentro do diretório 
src/App/src/Handler/Mensagem , conforme mostra a imagem 
a seguir: 
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Figura 14.9: Criando o Handler MensagemDeletarHandler 


Após a criação do Handler, vamos ver seu código 
completo a seguir: 


<?php 
declare(strict types=1); 


namespace App\Handler\Mensagem; 


use App\Handler\HandlerAbstract; 

use App\Service\MensagemService; 

use Psr\Http\Message\ResponselInterface; 

use Psr\Http\Message\ServerRequestinterface; 
use Psr\Http\Server\RequestHandlerInterface; 
use Zend\Diactoros\Response\JsonResponse; 


IER 
* Class MensagemDeletarHandler 
* @package App\Handler\Mensagem 
*/ 
Class MensagemDeletarHandler extends HandlerAbstract 
implements RequestHandlerInterface 
{ 
f= * 
* @param ServerRequestInterface $request 
* @return ResponseInterface 
A 
public function handle(ServerRequestInterface 
$request): ResponseInterface 


{ 
$id = (int)$request->getAttribute('id'); 


$service = $this->container- 
>get (MensagemService: :class); 
$messageDeleted = $service->delete($id); 


return new JsonResponse( [ 
'data' => $messageDeleted 
], 200); 


} 


Como você já sabe bem, esse código também não é 
complexo e existem apenas três diferenças se comparado 
com o código dos Handlers TipoUsuarioDeletarHandler € 
UsuarioDeletarHandler . 


A primeira diferença é o código  $service = $this- 
>container ->get(MensagemService::class) , que armazena 
na variável $service O serviço de mensagens 
propriamente dito. 


A segunda diferença está no código $messageDeleted = 
$service->delete($id) , que armazena na variável 
$messageDeleted O resultado da exclusão do registro de 
mensagem, que é a própria mensagem que foi deletada. 


A terceira diferença esta no retorno do método, pois a 
chave data recebe o resultado contido na variável 
$messageDeleted . 


Com isso, podemos avançar para o próximo passo para 
criarmos a Factory desse Handler. 


Criando a Factory MensagemDeletarHandlerFactory 


O objetivo dessa Factory é retornar a instância da classe 
MensagemDeletarHandler , para isso, crie a classe 
MensagemDeletarHandlerFactory dentro do diretório 

src/App/src/Handler/Factory/Mensagem , conforme mostra a 
imagem a seguir: 


v Em livro-zend-expressive 


SFC 


m; quo 


Doctrine 


amem É Er pls = 5 a mi mr Src Trike Farr 
ensada QEN Altei afnal dle: Fa CLOI vp D 


- 2 Se a en fae EA yee Se reyes eee 
1 MensagemCriarHandlerFactory.php 








Figura 14.10: Criando a Factory MensagemDeletarHandlerFactory 


Após a criação da Factory vamos ver como é o código 
completo dela a seguir: 


<?php 
declare(strict types=1); 
namespace App\Handler\Factory\Mensagem; 


use App\Handler\Mensagem\MensagemDeletarHandler ; 
use Interop\Container\ContaineriInterface; 


/** 
* Class MensagemDeletarHandlerFactory 
* @package App\Handler\Factory\Mensagem 
"7 

class MensagemDeletarHandlerFactory 


{ 
jer 
* @param ContainerInterface $container 
* @return MensagemDeletarHandler 
ay 
public function _ invoke(ContainerInterface 
$container): MensagemDeletarHandler 


{ 


return new MensagemDeletarHandler($container ); 


} 


Nao ha nenhum segredo, a Factory retorna exatamente o 
esperado, que é uma instância da classe 
MensagemDeletarHandler . 


O próximo e último passo é registrar o Handler no arquivo 
de configuração. 


Registrando o Handler MensagemDeletarHandler 


Para registrarmos, basta abrir O arquivo 
src/App/src/ConfigProvider.php e localizar o método 
getDependencies() . Logo abaixo do registro 
Handler \Mensagem\MensagemAlLterarHandler: :class que 


fizemos anteriormente, digite o código de registro a seguir: 


Handler \Mensagem\MensagemDeletarHandler::class => 
Handler \Factory\Mensagem\MensagemDeletarHandlerFactory::c 
lass 


Simples assim! Seu método getDependencies() deve ser 


parecido com o mostrado a seguir: 


public function getDependencies() : array 
{ 
return [ 
'invokables' => [ 
Handler\PingHandler::class => 
Handler\PingHandler::class, 
l, 
'factories' => [ 
Handler\HomePageHandler::class => 
Handler \HomePageHandlerFactory::class, 
Handler\TestDoctrineConnectionHandler::class 
=> 
Handler\Factory\TestDoctrineConnectionHandlerFactory::cla 
SS, 


//Handlers de Tipos de Usuário 


HandlerNTipoUsuarioNTipoUsuarioListarHandler::class => 
Handler \Factory\TipoUsuario\TipoUsuarioListarHandlerFacto 
ry::class, 


Handler\TipoUsuario\TipoUsuarioListarUmHandler::class => 
Handler \Factory\TipoUsuario\TipoUsuarioListarUmHandlerFac 
tory::class, 


Handler\TipoUsuario\TipoUsuarioCriarHandler::class => 
Handler \Factory\TipoUsuario\TipoUsuarioCriarHandlerFactor 
y::class, 


Handler\TipoUsuario\TipoUsuarioAlterarHandler::class => 
Handler \Factory\TipoUsuario\TipoUsuarioAlterarHandlerFact 
ory::class, 


Handler\TipoUsuario\TipoUsuarioDeletarHandler::class => 
Handler \Factory\TipoUsuario\TipoUsuarioDeletarHandlerFact 


ory::class, 


//Handlers de Usuários 

Handler\Usuario\UsSuarioListarHandler::class 
=> 
Handler \Factory\Usuario\UsSuarioListarHandlerFactory::clas 
S, 

Handler\Usuario\USuarioListarUmHandler::class 
=> 
Handler \Factory\Usuario\UsSuarioListarUmHandlerFactory::cl 
ass, 

Handler\Usuario\UsuarioCriarHandler::class => 
HandlerXFactoryXUsuarioXUsuarioCriarHandlerFactory::class 
1 

Handler\Usuario\UsuarioAlterarHandler::class 
=> 
Handler\Factory\Usuario\UsuarioAlterarHandlerFactory::cla 
SS, 

Handler\Usuario\UsuarioDeletarHandler::class 
=> 
Handler\Factory\Usuario\UsuarioDeletarHandlerFactory::cla 
SS, 


//Handlers de Mensagens 

Handler\Mensagem\MensagemListarHandler::class 
=> 
Handler\Factory\Mensagem\MensagemListarHandlerFactory::cl 
ass, 


Handler \Mensagem\MensagemListarUmaHandler::class => 
Handler \Factory\Mensagem\MensagemListarUmaHandlerFactory: 
“class, 

Handler \Mensagem\MensagemCriarHandler::class 
=> 
Handler \Factory\Mensagem\MensagemCriarHandlerFactory::cla 
SS, 


Handler \Mensagem\MensagemAlterarHandler::class => 
Handler \Factory\Mensagem\MensagemAlterarHandlerFactory: :c 
lass, 


Handler \Mensagem\MensagemDeletarHandler::class => 
Handler \Factory\Mensagem\MensagemDeletarHandlerFactory::c 
lass, 


//Registrando Servicos 
Service\TipoUsuarioService::class => 
Service\Factory\TipoUsuarioServiceFactory::class, 
Service\UsuarioService::class => 
Service\Factory\UsuarioServiceFactory::class, 
Service\MensagemService::class => 
Service\Factory\MensagemServiceFactory: :class 


1, 
i 
} 


Com isso chegamos ao final do capitulo e tambem da 
série de criação de Handlers. 


Conclusão 


Vimos neste capítulo como criar os Handlers responsáveis 
pelo gerenciamento das mensagens. Vimos também que 
não há segredo algum se comparado com os demais 
Handlers dos capítulos anteriores, uma vez que a 
estrutura é a mesma e não tivemos que realizar a 
reescrita completa do código. 


Você poderá criar quantos Handlers for necessário. 
Experimente criar Handlers diferentes para alguma outra 
tarefa específica, como a de mensagens, por exemplo. 
Você pode criar um Handler capaz de obter todas as 
mensagens de um usuário específico, ou até mesmo um 


Handler capaz de deletar todas as mensagens de um 
determinado usuário. 


Nessa sequência de três capítulos, foram demonstrados 
como criar Handler e Factories e como registrar cada um 
deles no arquivo de configuração, que é uma etapa muito 
importante, já que, sem registrarmos os Handlers, nossa 
aplicação não saberia da existência deles e não poderia 
utilizá-los. 


No próximo capítulo, vamos criar as rotas da nossa 
aplicação para que possamos chamá-las em alguma 
aplicação cliente como Postman, ou o próprio navegador, 
dependendo do tipo da rota, então siga em frente! 


CAPÍTULO 15 
Definindo e testando as rotas da 
aplicação 


Agora que já temos todos os nossos Handlers definidos, 
chegou a hora de definirmos as rotas da nossa aplicação. 
É por meio dessas rotas que faremos a criação, listagem, 
alteração e exclusão dos registros. 


Você se lembra da rota que criamos no capítulo 6 que 
realiza o teste de conexão do Doctrine? E que a definimos 
no arquivo config/routes.php ? Caso não se recorde disso 
não tem problemas, pois veremos a seguir. Caso você se 
recorde, então já deve saber que é nele que definiremos 
as rotas da nossa aplicação. 


Cada Handler que criamos nos capítulos anteriores 
possuirá a sua própria rota, logo teremos um total de 15 
(quinze) rotas. 


15.1 Definindo as rotas de tipos de usuários 


As primeiras rotas que vamos definir serão as de tipos de 
usuários que são pertencentes aos Handlers de tipos de 
usuários que criamos no capítulo 12. 


Para definirmos as rotas, vamos entender qual será o tipo 
de cada uma das rotas que vamos criar: 


Rota /api/tipos-de-usuarios/listar-todos 


Handler: TipousuarioListarHandler 

Tipo da rota: GET 

Motivo: esta rota é responsável por obter 
informações, logo o método HTTP responsável por 
isso é O GET , que será o tipo da rota. 


Rota /api/tipos-de-usuarios/listar-um/1 


e Handler: TipoUsuarioListarUmHandler 

e Tipo da rota: GET 

e Motivo: como esta rota também é responsável por 
obter informações, o tipo definido sera GET. 


Rota /api/tipos-de-usuarios/criar 


e Handler: TipoUsuarioCriarHandler 

e Tipo da rota: post 

e Motivo: é responsável por realizar a gravação de 
informações no banco de dados, sendo assim, o 
método HTTP a ser utilizado é o post, pois 
precisamos enviar um conjunto de dados no corpo 
da requisição. 


Rota /api/tipos-de-usuarios/alterar/1 


e Handler: TipoUsuarioAlterarHandler 

e Tipo da rota: pur 

e Motivo: esta rota é responsável por realizar a 
alteracáo dos dados do registro, logo o método 
HTTP indicado é o PuT OU O PATCH. À diferença 
entre eles é que o Pur é indicado quando 
desejamos alterar todos os dados de um 
determinado registro e o PATCH é quando 
desejamos alterar apenas alguns registros. 


Rota /api/tipos-de-usuarios/deletar/1 


e Handler: TipoUsuarioDeletarHandler 

e Tipo da rota: DELETE 

e Motivo: como o objetivo dessa rota é excluir um 
registro, o método HTTP indicado é O DELETE . 


Agora que temos as nossas rotas definidas, temos que as 
definir no código do nosso arquivo config/routes.php € é 
exatamente isso que faremos logo a seguir. 


Definindo a rota para listar os tipos de usuários 


Abra o arquivo config/routes.php €, logo abaixo da rota 
/api/test-doctrine-connection que criamos no capítulo 6, 
insira o código a seguir: 


Sapp->get( 
'/api/tipos-de-usuarios/listar-todos', 


App\Handler\TipoUsuario\TipoUsuarioListarHandler::class, 
'api.tipos-de-usuarios.listar-todos' 


); 


Agora vamos entender o que esse código está fazendo. O 
trecho $app->get significa que estamos definindo a rota 
do tipo cer do HTTP. Esse tipo de método é utilizado 
quando desejamos obter informações. 


O método get recebe 3 parâmetros em ordem, são eles: 


e 1º - Path - é a rota propriamente dita, ou seja, a rota 
que será chamada pela aplicação cliente para fazer 
a requisição. Em nosso caso, é a rota /api/tipos- 
de-usuarios/listar-todos . 


e 2º - Middleware/Handler - é o Handler que criamos 
anteriormente e que foi registrado no arquivo de 
configuração ConfigProvider.php . Deve ser 
exatamente o mesmo nome que foi definido neste 
arquivo. Em nosso caso, é o Handler 

AppNHandlerNTipoUsuarioNTipoUsuarioListarHandler::c 
lass , que é responsável por realizar a listagem de 
todos os tipos de usuários. 

e 3º - Name - é o nome que desejarmos dar para a 
rota. Esse parâmetro é opcional, mas em nosso 
código definimos o nome api.tipos-de- 
usuarios.listar-todos , mas você pode definir o 
nome que desejar, desde que o nome seja único 
para cada rota. 


Perceba como é simples definir uma rota no Zend 
Expressive. Esse pequeno trecho de código já funciona 
muito bem e mais adiante neste capítulo faremos os 
testes das rotas. 


Definindo a rota para listar apenas um tipo de usuário 


A próxima rota que vamos definir é que retornará apenas 
um tipo de usuário, com base no id que será informado 
como parâmetro da requisição. 


Com o arquivo config/routes.php aberto, digite ou insira o 
código a seguir: 


$app->get ( 
'/api/tipos-de-usuarios/listar-um/{id}', 


App\Handler\TipoUsuario\TipoUsuarioListarUmHandler: :class 


/ 


'api.tipos-de-usuarios. listar -um' 


); 


Perceba que essa rota também é do tipo GET igual a que 
definimos anteriormente. Veja o código  /api/tipos-de- 
usuarios/listar-um/{id} que estamos definindo, essa rota 
é responsável por retornar apenas um tipo de usuário e 
isso será possível graças ao parâmetro id que está 
definido entre chaves {}. 


No Handler TipousuarioListarumHandler , é esse parámetro 
que estamos recuperando e convertendo em numero 
inteiro para ser utilizado. 


Os demais trechos do código são basicamente os 
mesmos, mudando apenas o Handler que está sendo 
chamado e também o nome da rota. 


Definindo a rota para criar um registro de tipo de 
usuário 


Agora vamos definir a rota que será responsável por 
realizar a criação/inserção de registros de tipos de 
usuários. Veja a seguir como é o código de definição 
dessa rota: 


$app->post( 
'/api/tipos-de-usuarios/criar', 


App\Handler\TipoUsuario\TipoUsuarioCriarHandler::class, 
'api.tipos-de-usuarios.criar' 


); 


A primeira diferença a ser notada no codigo anterior é o 
trecho $app->post , que indica que estamos definindo uma 
rota do tipo post do HTTP. 


Esse tipo de rota é definido quando desejamos realizar 
inserção de dados e precisamos enviar um conjunto de 
dados no corpo da requisição. 


Perceba também que a estrutura do método $app->post é 
a mesma do método  gapp->get , OU Seja, possui 3 
parámetros: path, Handler € Name. 


Sempre que você for definir uma rota, lembre-se de 
informar o Handler correspondente que foi criado e 
registrado no arquivo de configuração 
ConfigProvider.php , isso é muito importante. 


Definindo a rota para alterar os dados de um registro 
de tipo de usuário 


Vamos definir agora como será o código de definição da 
rota responsável por realizar a alteração dos dados de um 
determinado registro de tipo de usuário por meio do id 
que será informado como parâmetro da URL. 


Veja a seguir como é o código de definição dessa rota: 


$app->put( 
'/api/tipos-de-usuarios/alterar/{id}', 


App\Handler\TipoUsuario\TipoUsuarioAlterarHandler::class, 
'api.tipos-de-usuarios.alterar' 


); 


A primeira diferença a notar no código é o trecho s$app- 
>put , que indica que estamos definindo uma rota do tipo 
put do HTTP. O método put é bem semelhante ao 
post . É indicado para realizar alteração de dados e, 
assim como o post , ele também permite enviar um 


conjunto de dados no corpo da requisição sem que o 
usuário veja os dados sendo enviados. 


Outra diferença é a presença do parâmetro id, que foi 
definido entre chaves O . Esse parâmetro será 
recuperado dentro do Handler TipoUsuarioAlterarHandler 
que criamos lá no capítulo 12. 


As demais diferencas sáo no Handler e no nome da rota, 
como vocé já sabe. 


Definindo a rota para deletar um registro de tipo de 
usuário 


A última rota de tipo de usuário que vamos definir é a que 
será responsável por excluir um registro de tipo de usuário 
com base no id que será informado como parámetro da 
URL. 


Vejamos a seguir como é o código dessa rota: 


$app->delete( 
-/ap1/tipos-de-usuarios/deletar/(id)3', 


App\Handler\TipoUsuario\TipoUSuarioDeletarHandler::class, 
'api.tipos-de-usuarios.deletar' 


); 


A diferenca desse código é o trecho sapp->delete , que 
informa que o tipo da rota é DeLeTe do HTTP. Esse 
método é indicado quando desejamos realizar a exclusão 
de registros do banco de dados. 


Perceba novamente a presença do parâmetro id definido 
entre chaves {} . Ele é recuperado e utilizado dentro do 


Handler TipoUsuarioDeletarHandler que criamos e 
registramos no capítulo 12. 


Além disso, note que a estrutura do método delete 
também náo foi alterada, se comparado com todos os 
demais métodos que utilizamos anteriormente neste 
capítulo. 


Vale lembrar que é muito importante atentar-se ao 
Handler que você criou e chamá-lo quando estiver 
definindo as suas rotas, nunca se esqueça disso. 


Agora que já definimos todas as rotas de tipos de 
usuários, nós realizaremos os testes para garantirmos que 
estão funcionando conforme o esperado. 


15.2 Testando as rotas de tipos de usuários 


Para realizar os testes, usaremos o Postman para fazer 
as requisições, mas você poderá utilizar outra aplicação 
capaz de fazer o mesmo. 


Testando a rota para criar um registro de tipo de 
usuário 


Com o Postman ou sua aplicação capaz de fazer 
requisições aberta, informe na URL o endereço 

http://livro-zend-expressive.dev/api/tipos-de- 
usuarios/criar . 


Altere o tipo de método HTTP para post e, no corpo da 
requisicáo, informe o código JSON a seguir: 


"tipo": "Visitante", 
"ativo": true 


} 


Vocé pode estar se perguntando: mas como sei que sao 
esses dados que devo enviar? 


A resposta é simples: por meio da sua entidade 
TipoUsuario que melhoramos la no capítulo 7. 


É importante mencionar que o nome do campo tem que 
ser exatamente o mesmo nome definido na propriedade 
da entidade, ou seja, tipo vai funcionar, enquanto Tipo 
não. Atente-se bem a isso, certo? 


Se vocé definiu a rota, o método a ser utilizado na 
requisição e o conjunto de dados corretamente, ao 
submeter a requisição você deverá ter uma resposta 
semelhante à mostrada na imagem a seguir: 


POST ~ herp:/ilivro-zend -expressive.dev/ap:/upos-de usuarios/criarXDEBUG SESSION START= 12601 








1 Body © 
form data x AN Form urliencoded © raw binary 
tol 
tipo”: “Visitante”, 
3 ativo : true 
4 
Bady ! (5 
Pretty E E ISOR = = 
l» i 
2 data”: { 
3 td , 
4 Tipe : itante 
5 1 ative true 
ne rtado en”: { 
f “date”: 2918-07-24 14:16:23,495955", 
3 "tinezone_type”: 3, 
> “timezone”: “America Sao_Pauylo 
ti ; 
zd alterado en": null, 
Ei, deletado en”: null 
23 } 
23 15 


Figura 15.1: Resposta da insercáo do tipo de usuário 


Testando a rota para alterar os dados de um registro 
de tipo de usuário 


Agora altere a URL no seu cliente de requisicáo para 

http://livro-zend-expressive.dev/api/tipos-de- 
usuarios/alterar/1 . Altere também o tipo da requisicáo 
para Pur e informe o JSON a seguir no corpo da 
requisição: 


{ 
"ativo": false, 
"alteradoEm": "2018-07-24 15:06:02" 


} 


Neste caso, estamos inativando o registro atraves do 


campo ativo , que possui valor false , e estamos 
informando a data da alteração do registro. 


Se você definiu novamente tudo corretamente, você 
deverá ter uma saída semelhante à mostrada na imagem 
a seguir: 





PUT ~ hrrp:/livro-zend-expressive dev/api/tipos-de-usuarios/alterar/1 
(1) Body @ Ed E Le 3 
form-data xwiwwformurencoded © raw binary IN lapplicato! 
1º {È 
2 “ativo”: false, 
3 "alteradoEn”: "2018-07-24 15:06:02” 
a) 
Body | (5) i 
Prey ores SON - = 
lv | 
2. data”: ( 
3 ’ id” a 1, 
4 "tipo": “Visitante”, 
4 “As ativo”: false, 
6° “criado em": ( 
/ date”: “2018-07-24 14:16:23.,000000", 
g "tinezone_type": 3, 
q “timezone : “America/Sao Paulo” 
19 , 
lly “alterado em": { 
12 “date”: "2018-07-24 15:16:07.938442", 
13 “timezone type : 3, 
13 ) “timezone”: "America/Sãao Paulo” 
15 , 
16 “deletado em”: null 
17 } 
18 |) 


Figura 15.2: Resposta da alteração do tipo de usuário 


Testando a rota para listar todos os registros de tipos 
de usuários 


LA 


Vamos testar a rota que é responsável por realizar a 
listagem de todos os registros de tipos de usuários 
inseridos no banco de dados. 


Para isso, informe a rota http://livro-zend- 
expressive.dev/api/tipos-de-usuarios/listar-todos que 
criamos anteriormente e, em seguida, altere o tipo de 
requisição para GET e submeta a requisição. 


Se tudo ocorreu bem, você deverá ter uma saída 
semelhante à exibida na imagem a seguir: 


GET ` http:/Aivro-zend-expressive. dev/api/tipos-de-usuarios/listar-todos 


Authorization T (1) opoo $ | 
Type No Auth Nv 
Body a de “oo E 
Pretty > É Rosh JSON + = 
le! 
2. “result with dal”: [ 
3° { 
i we 4-4, 
"tipo": “Visitante” 
6 is ativo”: false, 
7. criado em”: ( 
8 “date : 2018-07-24 14:16:23.000000 , 
9 “timezone type”: 3, 
10 “timezone: “America/Sao Paulo” 
ti }, 
12 ~ “alterado em": { 
23 “date”: 2018-07-24 15:16:07.000000 , 
¡A "timezone_type”": 3, 
15 "timezone": “America/Sao Paulo” 
16 }, 
17 deletado em": null 
1e } 
16 ], 
28» “result without dal”: [ 
te { 
22 a 3.1, 
23 “tipo : "Visitante", 
RE “ativo”; false 
26 ] 
27 ) 


Figura 15.3: Resposta da listagem de todos os tipos de usuários 


Um ponto importante a ser considerado: perceba que a 
chave result_with_dql possui todos os campos da 
entidade, enquanto o campo result without dql possui 
apenas alguns. Isso foi feito para mostrar a você a 
flexibilidade que você possui ao trabalhar com o Doctrine. 


Testando a rota para listar apenas um registro de tipo 
de usuário 


Agora vamos testar a nossa rota que retorna apenas um 
tipo de usuário com base no id que será informado na 
URL. Altere a URL em seu cliente de requisição para 

http://livro-zend-expressive.dev/api/tipos-de- 
usuarios/listar-um/1 . O tipo de requisição deve ser o 
mesmo, no caso o GET . Em seguida, submeta a 
requisição e veja se o seu resultado é semelhante ao 
obtido na imagem a seguir: 


GET ~ http:/flivro-zend-expressive.dev/api/tipos-de-usuarios/listar-um/1 








Authorization se po o DE ey eae a 
Type No Auth xy 
Body j (5) Jara 
Pretty | ¡SON ~ — 


"result with dgl”: ( 
"an 1 Le 
“tipo”: "Visitante", 
“ts ativo": false, 
” “criado em”: { 
“date”: "2018-07-24 14:16:23.000000", 
"timezone type”: 3, 
“timezone”: “America/Sao Paulo” 
11 > “alterado em”: { 
“date: “2018-07-24 15:16:07.000000", 
“timezone type: 3, 
“timezone : “America/Sao_ Paulo” 
“deletado em”: null 
Fo 
- “result without dgl”: [ 
a cer 
“tipo”: “Visitante”, 
“ativo”: false 


Figura 15.4: Resposta da listagem de apenas um registro de tipo de usuário 


Testando a rota para deletar um registro de tipo de 
usuário 


Por fim, vamos testar a ultima rota de tipos de usuários. 
Ela é responsável por deletar um registro de tipo de 
usuário do banco de dados. 


Para testá-la, informe a URL http://livro-zend- 
expressive.dev/api/tipos-de-usuarios/deletar/1 em seu 
cliente de requisição, altere o método da requisição para 
DELETE e, em seguida, submeta a requisição. 


Veja se o seu resultado obtido é semelhante ao mostrado 
na imagem a seguir: 


DELETE ~ http:/Aivro-zend-expressive.dev/api/tipos-de-usuarios/deletar/1 


Authorization 7 (1) Pos E ai E 


Type No Auth 


q 
q 

D 
"e 
Di 

y | 


v data”: { 
_initializer_": {}, 
__cloner_ "2: {}, 
_isInitialized__”: false 


y 
al 


Figura 15.5: Resposta da exclusáo de um registro de tipo de usuário 


Se o seu resultado for semelhante, pode ficar tranquilo, 
pois está tudo certo. A resposta é exatamente essa, isso 
ocorre porque, quando vamos deletar um registro, 
estamos buscando da entidade que foi gravada no cache 
lá dentro do diretório Proxy , aquele que definimos lá atrás 
no capítulo 6. 


Com isso, finalizamos a definição e testes das rotas de 


tipos de usuários e estamos prontos para seguir em 
frente. 


15.3 Definindo as rotas de usuários 


As próximas rotas que vamos definir serão as de usuários, 
que são pertencentes aos Handlers de usuários que 
criamos no capítulo 13. 


Vamos entender qual será o tipo de cada uma das rotas 
que vamos criar: 


Rota /api/usuarios/listar-todos 


Handler: usuarioListarHandler 

Tipo da rota: GET 

Motivo: esta rota é responsável por obter 
informações, logo o método HTTP responsável por 
isso é O GET , que será o tipo da rota. 


Rota /api/usuarios/listar-um/1 


e Handler: UsuarioListarumHandler 

e Tipo da rota: GET 

e Motivo: como essa rota também é responsável por 
obter informações o tipo definido sera GET . 


Rota /api/usuarios/criar 


e Handler: usuarioCriarHandler 

e Tipo da rota: post 

e Motivo: É responsável por realizar a gravação de 
informações no banco de dados, sendo assim, o 


método HTTP a ser utilizado é o post, pois 
precisamos enviar um conjunto de dados no corpo 
da requisição. 


Rota /api/usuarios/alterar/1 


e Handler: UsuarioAlterarHandler 

e Tipo da rota: pur 

e Motivo: esta rota é responsável por realizar a 
alteração dos dados do registro, logo o método 
HTTP indicado é o PuT ou o PATCH. À diferença 
entre eles é que o Pur é indicado quando 
desejamos alterar todos os dados de um 
determinado registro e o PATCH é quando 
desejamos alterar apenas alguns registros. 


Rota /api/usuarios/deletar/1 


e Handler: UsuarioDeletarHandler 

e Tipo da rota: DELETE 

e Motivo: como o objetivo dessa rota é excluir um 
registro, então o método HTTP indicado é O DELETE . 


Agora que temos as nossas rotas, temos que as definir no 
código do nosso arquivo config/routes.php . Antes, 
perceba que a tabela mostrada é exatamente a mesma da 
tabela de tipos de usuários que criamos no começo do 
capítulo, não houve alterações na explicação porque 
nossa aplicação segue exatamente a mesma estrutura, 
mudamos apenas as rotas e os Handlers. 


Vamos definir as rotas dentro da nossa aplicação. 


Definindo a rota para listar os usuários 


Antes de seguirmos, vale informar que a estrutura dos 
códigos de definição das rotas também é a mesma que já 
foi explicada anteriormente, mudando apenas a rota, o 
Handler e o nome da rota. Veja a seguir o código de 
definição da desta rota: 


Sapp->get ( 
'/api/usuarios/listar-todos', 
App\Handler\Usuario\USuarioListarHandler::class, 
'api.usuarios.listar-todos' 


); 


Definindo a rota para listar apenas um usuario 


y 


A próxima rota que vamos definir é a que retornará 
apenas um usuário baseado no id que será informado 
como parámetro da requisicáo. 


Digite ou insira o código a seguir em seu arquivo 
config/routes.php : 


Sapp->get( 
'/api/usuarios/listar-um/{id}', 
App\Handler \USuario\USuarioListarUmHandler::class, 
'api.usuarios.listar-um' 


); 
Definindo a rota para criar um registro de usuário 


Agora vamos definir a rota que será responsável por 
realizar a criação/inserção de registros de usuários, veja O 
código a seguir: 


$app->post( 
'/api/usuarios/criar', 
AppMHandlerXUsuarioXUsuarioCriarHandler::class, 


'api.usuarios.criar' 


); 


Definindo a rota para alterar os dados de um registro 
de usuario 


Vamos definir agora como sera o código de definição da 
rota responsável por realizar a alteração dos dados de um 
determinado registro de usuário por meio do id , que será 
informado como parâmetro da URL. 


Sapp->put ( 
'/api/usuarios/alterar/{id}', 
App\Handler \Usuario\USuarioAlterarHandler::class, 
'api.usuarios.alterar' 


); 
Definindo a rota para deletar um registro de usuário 


A última rota de usuários que vamos definir é a que será 
responsável por excluir um registro de usuário com base 
no id que será informado como parâmetro da URL. 


Veja a seguir o código dessa rota: 


$app->delete( 
'/api/usuarios/deletar/(id+', 
App\Handler \USuario\USuarioDeletarHandler::class, 
'api.usuarios.deletar' 


); 


Pronto, finalizamos a definição das rotas de usuários e 
como você pôde ver não mudou muita coisa, inclusive a 
estrutura de definição das rotas é a mesma. Como foi 
descrito anteriormente, apenas mudamos as rotas, os 


Handlers e o nome das rotas. 


Agora podemos realizar os testes para verificarmos se 
tudo está funcionando corretamente. 


15.4 Testando as rotas de usuários 


Como você já sabe, estou utilizando o Postman para 
realizar os testes, mas você poderá utilizar outra aplicação 
capaz de realizar as requisições. 


Testando a rota para criar um registro de tipo de 
usuário 


Antes de prosseguirmos, é importante lembrar que, como 
excluímos o registro de tipo de usuário com o nosso 
ultimo teste, será necessário criá-lo novamente. Esse 
passo você deverá fazer por meio da requisição de criar 
tipo de usuário. Depois siga para o passo descrito a 
seguir. 


Com o seu cliente de requisições aberto, informe na URL 
O endereco http://livro-zend- 
expressive.dev/api/usuarios/criar . 


Altere o tipo de método HTTP para post e, no corpo da 
requisicáo, informe o código JSON a seguir: 


{ 
"tipoUsuario": 4, 
"nomeCompleto": "Nome Completo do Usuario", 
"cof": "85525545595", 
"dataNascimento": "19100-06-06", 
"email": "emaildousuario@dominio.com.br", 
"senha": "123456", 


"ativo": true 


} 


No conjunto de dados a ser enviado para a requisição, 
não há segredo algum. O único ponto a ser levado em 
consideração e é extremamente importante é a chave 
tipoUsuario . Essa chave deve possuir o id do registro 
de tipo de usuário existente; caso o valor inexistente seja 
informado, um erro ocorrerá. Logo, atente-se a isso, pois 
você deverá informar um id de tipo de usuário existente 
em seu banco de dados. 


Com tudo preparado e pronto para ser enviado, submeta 
a requisição. 


Se o resultado obtido for semelhante ao mostrado na 
imagem a seguir, significa que está tudo certo e 
poderemos seguir em frente: 


POST ~= htrp://lvro-zend-expressive dev/api'usuarios/criar?XDEBUG SESSION START=13739 


form-data wern-form-urlencoded É raw binary SON fapolcatiorn/ison 
lv { 
É. "tipoUsuario™: 4, 
3 “nomecompleto”™: "Nome Completo do Usuário”, 
4 “cpf”: "35525545595", 
5 "dataNascimento”: “1996-06-06”, 
b “email”: “ematldousuariofdoninio. com.br”, 
7 “senha”: "123456", 
3 “ativo : true 
9 | 
Body 1 (5) Hoc 
Prey 7 pes SON. sD 
> { 
, data”: { 
a's Le 
“nome Leto”: “Nome Completo do Usuario”, 


-corp 
“cpf”: "35525545595", 
“data nascimento”: { 
“date”: "1990-06-06 00:00:00.000099", 
"timezone_type”: 3, 
"timezone: “Anerice/Seo Paulo” 


e 
QL -4 UN se Ls hee 
4 


"email": "emaildousuartogdoninio. com.br”, 
“senha”: “elBadcIs49baSSabbe56e057f20f993e”, 
“As ativo”: true, 
y “criado em”: { 
“date”: “2618-67-25 16:44:62.069115", 
“timezone_type™: 3, 
“timezone”: “America/Sao Paulo” 


ye o 


“alterado em”: null, 

“deletado em”: null, 
> “tipo usuario”: ( 
* initializer_ *: {), 
cloner": 1), 
isInitialized_”: false 


ereto qu na .*. no 
Dt T -e T P fo qu “Ino 


_ 


SN PIP DO 
AM be Lu hee mm 


Figura 15.6: Resposta da inserção de um registro de usuário 


Testando a rota para alterar os dados de um registro 
de usuario 


Agora altere a URL no seu cliente de requisição para 
http://livro-zend-expressive.dev/api/usuarios/alterar/1 , 


altere também o tipo da requisição para pur e informe o 
JSON a seguir no corpo da requisição: 


{ 
"nomeCompleto": "Nome Completo do Usuário de Teste", 
"cof": "453335867157, 
"dataNascimento": "2000-01-01", 
"email": "emaildousuario@dominio.com", 
"Senha": "123", 
"ativo": false, 
"alteradoEm": "2018-07-25 11:00:15" 
} 


Nesse caso, estamos inativando o registro atraves do 
campo ativo igualmente fizemos com o registro de tipo 
de usuário que possui valor false e estamos informando 
a data da alteração do registro. Também estamos 
alterando todos os demais campos. 


Se você definiu tudo corretamente, então você deverá ter 
uma saída semelhante à mostrada na imagem a seguir: 


WO Go sl OT LA dos tod Pd pa 


Wo CD Ch Ln fe lu Pl ta 


PUT 


4 
= 


pr cl 


4 


hitp://livro-zend-expressive.dev/api/usuarios/alterary 1 


“nomeCompleto": "Nome Completo do Usuário de Teste”, 
“cpf”: "45333586715", 

“dataNascimento”: "2000-01-01", 

“email”: “emaildousuariofdominio. com”, 

“senha”: “123”, 

“ativo”: false, 

“alteradoEm": "2018-07-25 11:00:15” 


“data”: { 
"sd, 
“nome completo”: "Nome Completo do Usuário de Teste”, 
“cpf”: "45333586715", 
“data nascimento”: { 
“date”: "2000-01-01 00:00:00.000006”, 
“timezone type”: 3, 
“timezone”: “America/Sao Paulo” 


E 1 


email”: "emaildousuariofdominio.com”, 
“senha”: *2062cb962ac59075b964b07152d234b70", 
is ativo”: false, 
criado em": { 
“date”: "2618-07-25 10:44:02.000000", 
“timezone type": 3, 
“timezone”: “America/Sao Paulo” 


sm 


i 
“alterado em": { 
“date”: "2018-07-25 11:32:20.876813”, 
“timezone type”: 3, 
“timezone: “America/Sao Paulo” 


a 
“deletado em": null, 
“tipo usuario”: { 

” initializer_": {}, 

" cloner_ ": {}, 

* 1isInitialized_": false 


Figura 15.7: Resposta da alteração dos dados do usuário 


Testando a rota para listar todos os registros de 
usuários 


Vamos testar a rota que é responsável por realizar a 
listagem de todos os registros de usuários inseridos no 
banco de dados. Para isso, informe a rota http://livro- 
zend-expressive.dev/api/usuarios/listar-todos l em 
seguida, altere o tipo de requisição para cer e submeta a 
requisição. 


Se tudo ocorreu bem, você deverá ter uma saída 
semelhante à mostrada na imagem a seguir: 


GET ~ hrip:fiivro-zend-expressive deviapilusuarios/listar-todos 
Key Value 
Content-Type appécationígson 
Body E (3) T | 
Pretty tar ete JSON ~ 5 


es 


“result with dal”: [ 


444 


W : i, 
“nome completo”: “Nome Completo do Usuário de Teste”, 
“cpf : "45333586715", 
X “data nascimento”: { 
“date”: 2009-01-01 00:00:06.00966009", 
“timezone type": 3, 
“timezone : “America/Sao Paulo” 
bran": "emaildousuariofdominio.con”, 
“senha”: “2082¿cb962ac59075b564007152d234b76", 
“ts ativo”: false, 
“criado em: 1 
“date”: "2018-07-25 10:44:02.000000", 


“timezone tune” 1 


a El pe £ pi Ll l 
a Aa as bu ee AO O =] Os rr A Lar A 


4 





p> A T q e = -p 
13 timezone”: "AnericafSao Paulo 


20 ~ “alterado en": { 

21 “date”: “2618- 67-25 11:32:20,096000", 
2d “timezone type”: 3, 

2] “timezone: “AnericafSao | Paulo” 

¿dl ‘ 

25 “deletado em": null, 

Ph + “tipo usuario : { 

27 _initializer_“: {}, 

23 crooner: th 

E; "isInitialized ": false 

34 } 

31 } 

32 

31” “result without dgl”: [ 

34 = | 

35 ln ee 

35 "ronticapilito : "Nome Completo do Usuário de Teste”, 
il “ativo: false, 

ad “cpf”: "45333586715", 

i9 "dataNascimento”: { 

Ai “date”: “7000-01-01 60:00:60. 690008" 
“11 “tinezone type”: 3, 

a2 "timezone": "AnericafSao_ Paulo” 

43 i 

aj “email”: “emaildousuar iogdoninio.con”, 
43 "tipolisuario”: 4 

Pal } 

q7 ] 

aB | 


Figura 15.8: Resposta da listagem de todos os usuários 


Testando a rota para listar apenas um registro de 
usuário 


Agora vamos testar a nossa rota que retorna apenas um 

usuário com base no id que será informado na URL. 

Altere a URL em seu cliente de requisição para 

http://livro-zend-expressive.dev/api/usuarios/listar- 

um/1 , O tipo de requisição deve ser o mesmo, no caso o 

T . Em seguida, submeta a requisição e veja se o seu 
resultado é semelhante ao obtido na imagem a seguir: 


{a 
ai 


GET ~ hup./Aivro-zend-expressive dev/apifusuarios/listar-uim/] 





Key Value 
Content-Type application/json 
Body 12-42-2488 | 

—_— 
Pretty JSON ~ = 
deal 
2. “result mith dal”: { 
3 “O: Li 
4 "nome completo”: "Nome Completo do Usuário de Teste”, 
5 “cpf”: "45333586715", 
be “data nascimento”: { 
7 “date”: “2660-61-61 60:66:66.000006", 
6 "timezone type": 3, 
9 ) “timezone : “America/Sao Paulo” 
19 n 
11 “email”: “emaildousuariofdominio.com”, 
12 “senha”: "202cb962ac59075b964b07152d234b70", 
13 "is ativo”: false, 
14° "criado em”: (| 
15 “date”: "2618-07-25 10:44:602.0090006", 
16 "timezone_type”: 3, 
17 “timezone”: "America/Sao_Paulo” 
18 Mo 
We alterado en”: { 
70 “date”: "2018-07-25 11:32:26.000006", 
z1 “timezone type”: 3, 
¿2 ) “timezone : "America/Sao Paulo” 
23 A 
24 “deletado em”: null, 
is. “tipo usuario”: { 
26 ” initializer_ *: (), 
¿7 "_cloner_”: (), 
<8 “_isInitialized_“: false 
¿9 
30 ), 
31- — [ 
sé 
a4 an E? 
14 "nomeCompleto”: “Nome Completo do Usuário de Teste”, 
35 ativo”: false, 
36 “cpf”: "45333586715", 
37» “dataNascimento”: { 
78 “date”: "2000-01-01 06:06:99. 000000", 
39 “timezone type”: 3, 
46 “timezone”: “Anerica/Sao Paulo” 
úl 
4 “email”: "emaildousuariofdorminio.com”, 
¿3 "tipoUsuario”: 4 
24 } 
45 ] 


Figura 15.9: Resposta da listagem de apenas um registro de usuário 


Testando a rota para deletar um registro de usuário 


Por fim, vamos testar a ultima rota de usuários, 
responsável por deletar um registro de usuário do banco 
de dados. 


Para testá-la, informe a URL http://livro-zend- 
expressive.dev/api/usuarios/deletar/1 em seu cliente de 
requisição, altere o método da requisição para DELETE e, 
em seguida, submeta a requisição. Veja se o seu 
resultado obtido é semelhante ao mostrado na imagem a 
seguir: 


DELETE http:/Mivro-zend-expressive dev/api/usuarios/deletar/1 
Authorization Ej 7) 

Type No Ath 
Body i (5) | | | 

Pretty Te bree ae, JSON + 5 

ir 

2 data”: { 

E _ initializer_": {}, 

4 _ cloner_*: fl, 

5 _ isInitialized ": false 

É } 

7 B 


Figura 15.10: Resposta da exclusão de um registro de usuario 


Se o seu resultado for semelhante, entao esta tudo certo. 
Com isso, finalizamos a definição e testes das rotas de 


usuários e estamos prontos para seguir em frente. 


15.5 Definindo as rotas de mensagens 


As próximas rotas que vamos definir serão as de 
mensagens que são pertencentes aos Handlers de 
mensagens que criamos no capítulo 14. 


Vamos entender qual será o tipo de cada uma das rotas 
que vamos criar. Você vai perceber novamente que nada 
mudará na descrição das rotas e nem nos tipos. 


Rota /api/mensagens/listar-todas 


Handler: MensagemListarHandler 

Tipo da rota: GET 

Motivo: esta rota é responsável por obter 
informações, logo o método HTTP responsável por 
isso é O GET , que será o tipo da rota. 


Rota /api/mensagens/listar-uma/1 


e Handler: MensagemListarUmHandler 

e Tipo da rota: GET 

e Motivo: como esta rota também é responsável por 
obter informações, o tipo definido será GET . 


Rota /api/mensagens/criar 


e Handler: mMensagemCriarHandler 
e Tipo da rota: post 


e Motivo: é responsável por realizar a gravação de 
informações no banco de dados, sendo assim, o 


método HTTP a ser utilizado é o post, pois 
precisamos enviar um conjunto de dados no corpo 
da requisição. 


Rota /api/mensagens/alterar/1 


e Handler: mensagemalterarHandler 

e Tipo da rota: pur 

e Motivo: esta rota é responsável por realizar a 
alteração dos dados do registro, logo o método 
HTTP indicado é o put ou o PATCH. À diferença 
entre eles é que o Pur é indicado quando 
desejamos alterar todos os dados de um 
determinado registro e o PATCH é quando 


desejamos alterar apenas alguns registros. 
Rota /api/mensagens/deletar/1 


e Handler: MensagemDeletarHandler 

e Tipo da rota: DELETE 

e Motivo: como o objetivo dessa rota é excluir um 
registro, então o método HTTP indicado é O DELETE . 


Agora que temos as nossas rotas definidas, temos que as 
definir no código do nosso arquivo config/routes.php . 


Agora vamos definir as rotas dentro da nossa aplicacáo. 
Definindo a rota para listar as mensagens 


A estrutura é a mesma que já conhecemos. Veja a seguir 
o código de definicáo da desta rota: 


$app->get ( 
'/api/mensagens/listar-todas', 


App\Handler\Mensagem\MensagemListarHandler::class, 
'api.mensagens. listar-todos' 


); 
Definindo a rota para listar apenas uma mensagem 


A próxima rota que vamos definir é a que retornará 
apenas uma mensagem com base no id que será 
informado como parâmetro da requisição. 


Insira o código a seguir em seu arquivo 
config/routes.php : 


Sapp->get ( 
'/api/mensagens/listar-uma/{id}', 
App\Handler \Mensagem\MensagemListarUmaHandler::class, 
'api.mensagens.listar-uma' 


); 
Definindo a rota para criar um registro de mensagem 


Agora vamos definir a rota que será responsável por 
realizar a criacáo/insercáo de registros de mensagens. 
Veja o código a seguir: 


$app->post( 
'/api/mensagens/criar', 
App\Handler \Mensagem\MensagemCriarHandler::class, 
'api.mensagens.criar' 


); 


Definindo a rota para alterar os dados de um registro 
de mensagem 


Vamos definir agora como sera o código de definição da 
rota responsável por realizar a alteração dos dados de um 


determinado registro de mensagem através do id que 
será informado como parâmetro da URL. 


Sapp->put ( 
'/api/mensagens/alterar/(id+', 
App\Handler \Mensagem\MensagemAlLterarHandler::class, 
'api.mensagens.alterar' 


); 


Definindo a rota para deletar um registro de 
mensagem 


A última rota de mensagens que vamos definir é a 
responsável por excluir um registro de mensagem com 
base no id que será informado como parámetro da URL. 


Veja a seguir o código dessa rota: 


$app->delete( 
'/api/mensagens/deletar/{id}', 
App\Handler \Mensagem\MensagemDeletarHandler::class, 
'api.mensagens.deletar' 


); 


Finalizamos a definição das rotas de mensagens e de 
todas as rotas da aplicação. Como você pôde ver e já 
sabe bem, não mudou muita coisa. 


Agora podemos realizar os testes para verificarmos se 
tudo está funcionando corretamente. 


15.6 Testando as rotas de mensagens 


Aqui estamos utilizando o Postman para realizar os testes, 


mas você poderá utilizar outra aplicação capaz de realizar 
as requisições. 


Testando a rota para criar um registro de mensagem 


Antes de prosseguirmos, devemos criar um novo registro 
de usuário, pois no último teste realizamos a exclusão do 
usuário. Esse passo você deverá fazer por meio da 
requisição de criar usuário. Depois siga para o passo 
descrito a seguir. 


Com o seu cliente de requisições aberto, informe na URL 
O endereco http://livro-zend- 
expressive.dev/api/mensagens/criar . 


Altere o tipo de método HTTP para post e no corpo da 
requisição, informe o código JSON a seguir: 


{ 
"usuario": 2, 
"mensagem": "Ola, isso é uma mensagem de teste.", 
"ativo": true 

Í 


No conjunto de dados a ser enviado para a requisição, o 
unico ponto a ser levado em consideração, e que é 
extremamente importante, é a chave usuario . Essa 
chave deve possuir o id do registro de usuário existente; 
caso o valor inexistente seja informado, um erro ocorrerá, 
então atente-se a isso. 


Com tudo preparado e pronto para ser enviado, submeta 
a requisição. Se o resultado obtido for semelhante ao 
mostrado na imagem a seguir, significa que está tudo 
certo: 


POST ~ http //lvro-zend-expressive.dev/api/mensagens/criad 





form-data x-wwa-form-uencoded * raw binary ¡SON lapplication/ison) ~ 
te { 
2 “usuario”: 2, 
3 “mensagen”: “Ola, isso é uma mensagen de teste.”, 
4 “ativo”: true 
5} 
Body (5) 
Pretty SON $ 
E { 
” “data”: { 
l n p 
“mensagen”: “Ola, isso é uma mensagen de teste.”, 
“resposta”: null, 
E. "data mensagen”: { 
“date”: “2018-07-25 13:38:58.018161", 
“timezone type”: 3, 
“tinezone : “America/Sao Paulo” 
$, 
11 ts ativo : true, 
- “criado em": { 
"date": "2018-07-25 13:38:57.966492", 
“timezone type: 3, 
“timezone”: “America/Seo Paulo” 
“alterado em”: null, 
16 "deletado en”: null, 
i+ “usuario”: { 
"initializer": {}, 
"__cloner_": {}, 
" isinittialized ”: false 
VE } 
25 @ 


Figura 15.11: Resposta da inserção de um registro de mensagem 


Perceba que na resposta que obtemos o campo resposta 
está null, isso porque quem responderá a mensagem 
será a nossa requisição de alteração de dados logo a 
seguir. 


Testando a rota para alterar os dados de um registro 
de mensagem 


Agora altere a URL no seu cliente de requisição para 

http://livro-zend- 
expressive.dev/api/mensagens/alterar/1 . Altere também o 
tipo da requisição para pur e informe o JSON a seguir no 
corpo da requisição: 


{ 

"resposta": "Ola, sua mensagem foi respondida pelo 
teste.", 

"alteradoEm": "2018-07-25 13:48:00" 
} 


Nesse caso, estamos respondendo a mensagem do 
usuário e informando a data de alteração do registro, 
então se você definiu tudo corretamente, você deverá ter 
uma saída semelhante à mostrada na imagem a seguir: 


PUT > http://livro-zend-expressive dev/api/mensagens/alterar/1 





lo { 
2 “resposta”: “Ola, sua mensagen foi respondida pelo teste.”, 
3 “alteradoEn”: "2018-07-25 13:48:00" 
3 3 
Body (5) I 
Pretty ISON = 
i ae 
2 ~ data”: { 
3 "4a": 4, 
- “mensagen”: “Olê, isso é uma mensagen de teste.”, 
5 “resposta”: “Olê, sua mensagem foi respondida pelo teste,”, 
e "data mensagen”: ( 


“date”: "2018-07-25 13:38:58.000000”, 
“tirezone type : 3, 
“timezone”: "America/Sao Paulo” 


11 “As ativo”: true, 

12 » “criado em”: 
“date”: "2018-07-25 13:38:57.000000", 
“timezone type": 3, 
“tinezone : “America/Sao Paulo” 


17 » “alterado em": { 

18 “date : 2018-07-25 13:50:56,525290", 
"timezone type”: 3, 
“timezone”: "America/Sao Paulo” 


22 “deletado em": null, 
23 v “usuario”: ( 


* initializer_”: {}, 
” cloner_": {}, 
"isInitialized_": false 
¿i } 
23 } 
29 3 


Figura 15.12: Resposta da alteração dos dados da mensagem 


Perceba que dessa vez o campo resposta foi preenchido, 
ou seja, funcionou corretamente. 


Testando a rota para listar todos os registros de 
mensagens 


y 


Vamos testar a rota que é responsável por realizar a 


listagem de todos os registros de mensagens inseridas no 
banco de dados. Para isso, informe a rota http://livro- 
zend-expressive.dev/api/mensagens/listar-todos e, em 
seguida, altere o tipo de requisicáo para cer e submeta a 
requisição. 


Se tudo ocorreu bem, você deverá ter uma saída 
semelhante à mostrada na imagem a seguir: 


GET 


httpi/flivro-zend-expressive. dev/api/fmensagensilistar-todas 


Authorization ber. (1) 
oe SS 


Type 





Em 


Fa ras rar Ha bl ta 
C =} m L þa L d 


ra Ha 


“result with dgl": [ 


"id": 1, 


No Auth a 


“mensagen”: "Olá, isso é uma mensagen de teste.”, 
“resposta”: “Ola, sua mensagen foi respondida pelo teste.”, 
“data mensagen”: { 

“date”: 

“timezone type": 3, 

“timezone: “America/Sao Paulo” 


"2818-07-25 13:38:58.000008”, 


i 
"ie ativo”: true, 
“criado en": { 
“date”: "2618-07-25 13:38:57.606006", 
“timezone type”: 3, 
“timezone”: "America/Sao Paulo” 


}, 

“alterado em": { 
“date”: “2018-67-25 13:50:56.000000", 
“timezone type”: 3, 
“timezone”: “America/Sao Paulo” 


“deletado en": null, 
“usuario”: { 
*_initializer_“: {}, 

“loner "s i}, 
"_isInitialized_": false 


r 
+ 
. 
a 


“Ola, isso é uma mensagen de teste.”, 


} 

4 

“result without dal": [ 
Mure i, 
“mensagen” 
“resposta” 


“Olá, sua mensagen foi respondida pelo teste.”, 


“dataMensagen”: { 
“date”: “2618-67-25 13:38:58,600696", 
"timezone_ type”: 3, 
“timezone”: “America/Sao Paulo” 


J 
“ativo”: true, 


“usuario”: 


2 


Figura 15.13: Resposta da listagem de todas as mensagens 


Testando a rota para listar apenas um registro de 
mensagem 


Agora vamos testar a rota que retorna apenas uma 
mensagem com base no id que será informado na URL. 
Altere a URL em seu cliente de requisição para 
http://livro-zend-expressive.dev/api/mensagens/listar- 
uma/1 , O tipo de requisição deve ser o mesmo, no caso o 
GET . Em seguida, submeta a requisição e veja se o seu 
resultado é semelhante ao obtido na imagem a seguir: 


GET ~ http:/fivro-zend-expressive .dev/api/mensagens/listar-uma/1 





Authorization a | ee ee pode 
Type ho Auth 
Body Cookies Headers (5) Test Results 
o 
Pretty Raw Preview JSON vw =D 
i-{ 
2v “result with dal”: ( 
3 a whe = 
4 “mensagem”: “Ola, isso é uma mensagem de teste.”, 
5 resposta”: "Ola, sua mensagen foi respondida pelo teste.”, 
É~ data mensagen: { 
7 "date": "2018-07-25 13:38:58. 000090”, 
E “timezone type”: 
9 "tinezone”: "Anerica/Sao | Paulo” 
16 , 
11 ts ativo”: true, 
12 » “crtado em”: { 
13 "date": "2018-07- 13:38:57.000000”, 
14 “timezone type: 
15 ) “timezone: A Paulo” 
16 $ 
17 » “alterado_ en”: { 
18 “date”; "2618- 07- =” 13:50:56.000000", 
19 "timezone_ type”: 
26 "timezone: AE Paulo” 
21 e 
22 ci ns null, 
23 +» “usuario”: ( 
24 p —initializer PL ER, 
25 "cloner 
26 z mri Te : false 
27 
28 A 
29 » result without dal”: [ 
38 ~ ( 
31 “id”: 1, 
32 “mensagen”: “Ola, isso é uma mensagen de teste.”, 
33 “resposta”: “Ola, sua mensagem foi respondida pelo teste.”, 
34 + "dataMensagen 
35 “date”: : "2018- 07- 25 13:38:58.000000", 
36 “timezone type”: 3, 
37 “timezone”: "America/Sao Paulo” 
38 p 
39 “ativo”: true, 
40 “usuario”: 2 
41 
42 ] 
4a 1 


Figura 15.14: Resposta da listagem de apenas um registro de mensagem 


Testando a rota para deletar um registro de usuário 


Por fim, vamos testar a última rota de mensagens e a 
ultima rota da nossa aplicação. Essa rota é responsável 
por deletar um registro de mensagem do banco de dados. 


Para testá-la, informe a URL http://livro-zend- 
expressive. dev/api/mensagens/deletar/1 em seu cliente de 
requisição, altere o método da requisição para DELETE €, 
em seguida, submeta a requisição. Veja se o seu 
resultado obtido é semelhante ao mostrado na imagem a 
seguir: 


DELETE >œ http://livro-zend-expressive.dev/api/mensagens/deletar/1 


Authorization ro, = (ie E ae. a ias 


Type No Auth 
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Figura 15.15: Resposta da exclusáo de um registro de mensagem 


Finalizamos a definição e testes das rotas de mensagens. 
Com isso chegamos ao final do capítulo e, se você não 
teve nenhum problema até aqui, então você conseguiu 
concluir com sucesso a criação e a definição das rotas da 
aplicação. 


Caso você tenha tido algum problema devido a erros, 
tente revisar os passos com calma e atenção, que tudo 
funcionará corretamente. Se mesmo assim algum erro for 
persistido, você poderá mandar uma mensagem em meu 
e-mail jhones.developer@gmail.com , que ficarei feliz em 
ajudá-lo. 


Um ponto importante a ser considerado: se você abrir o 
seu repositório MensagemRepository , vera que nele existe 
um método chamado getMessagesFromuser . Esse método 
é responsável por obter todas as mensagens de um 
determinado usuário e ele não foi implementado de 
propósito. Então, como uma pequena lição, tente criar e 
registrar o Handler responsável por utilizá-lo. Crie também 
o método no serviço e, por fim, defina a rota para esse 
Handler e teste a sua aplicação. 


Conclusão 


Vimos neste capítulo como definir as rotas da aplicação e 
também como testá-las. Como você pôde ver, nao foram 
códigos complexos e grandes. 


No momento de definir as suas rotas, atente-se ao 
Handler que você deverá chamar e também a rota. Tente 
criar rotas simples e intuitivas, pois rotas muito grandes 
acabam confundindo tanto o desenvolvedor que a criou, 
quanto desenvolvedores terceiros. 


Em nosso próximo capítulo, vamos falar rapidamente 
sobre as PSRs 7 e 15 com que o Zend Expressive é 
compatível. Siga em frente e vamos nessa! 


CAPÍTULO 16 


Conhecendo as PSRs 7 e 15 


Você sabe o que é PSR? Já ouviu falar ou já teve 
contato? Caso não conheça, a PSR ou PHP Standard 
Recommendation (Padrão Recomendado para PHP, em 
português) são especificações que foram definidas pelos 
membros do PHP-FIG. Existem inúmeras PSRs, mas 
neste capítulo focaremos na PSR-7 e na PSR-15. 


O que É o PHP-FIG? 


E um grupo que tem foco em definir padrões de 
desenvolvimento para o PHP. Esses padrões vão 


desde o carregamento de classes, regras de 
formatação do código-fonte etc. Dentre os membros 
que fazem parte desse grupo temos: Zend 
Framework, Symfony e Slim. 





E importante saber que o PHP-FIG define algumas 
palavras-chaves dentro das PSRs que servem como uma 
Identificação no projeto, são elas: 


MUST - DEVE 

MUST NOT - NÃO DEVE 
REQUIRED - OBRIGATÓRIO 
SHALL - TEM QUE 

SHALL NOT - NÃO TEM QUE 
SHOULD - DEVERIA 

SHOULD NOT - NÃO DEVERIA 


e RECOMMENDED - RECOMENDADO 
e MAY - PODE 
e OPTIONAL - OPCIONAL 


Agora que você já sabe, vamos conhecer a PSR-7 na 
seção a seguir. 


16.1 PSR-7 (HTTP Message Interfaces) 


O principal intuito dessa PSR é fornecer interfaces em 
comum para a troca de mensagens HTTP. Para que as 
aplicações possam se comunicar de maneira mais fácil, 
criou-se um padrão que é exatamente esse conjunto de 
interfaces definidas pela PSR-7 juntamente com suas 
regras. Hoje muitos sistemas ainda se comunicam de 
maneiras diferentes e constantemente os 
desenvolvedores devem ficar estudando como uma 
determinada aplicação se comunica. Essa PSR visa tornar 
a nossa vida mais fácil também, então vamos conhecer 
suas regras. 


Mensagens 


Antes de prosseguirmos, você sabe o que é uma 
mensagem HTTP? Caso não saiba ou tenha dúvidas aqui 
vai uma breve explicação. Uma mensagem HTTP nada 
mais é do que uma requisição que uma aplicação faz para 
um servidor ou uma resposta de um servidor para a 
aplicação. 


Essa PSR define interfaces para as mensagens HTTP 
Psr\Http\Message\Requestinterface e 


Psr\Http\Message\ResponseiInterface respectivamente. 
Ambas as interfaces estendem 
Psr\Http\Message\MessageInterface . Enquanto a interface 
Psr\Http\Message\MessageInterface PODE ser 
implementada diretamente, as classes concretas DEVEM 
implementar Psr\Http\Message\RequestiInterface e 
Psr\Http\Message\ResponselInterface . 


Cabecalhos HTTP 


O nome dos cabecalhos devem ser case-insensitive, isto 
é, não deve fazer a distinção de letras maiúsculas e 
minúsculas, por exemplo, o cabeçalho Authorization 
deve ser interpretado da mesma maneira que se fosse 
escrito authorization . Os cabeçalhos são recuperados 
através das classes que implementam a interface 

Psr\Http\Message\MessageInterface . Vamos analisar o 
exemplo a seguir que demonstra exatamente o 
funcionamento dessa regra: 


<?php 
namespace App\Middleware\Authorization 
use PsriHttpiMessageiMessageInterface; 


class AuthorizationMiddleware 


{ 
private $mensagem; 
public function __construct(MessageInterface 
$mensagem) 


{ 


$this->mensagem = $mensagem; 


public function defineHeader() 


{ 
$mensagem = $this->mensagem- 
>withHeader('authorization', 'Bearer AbcDef12340+'>; 


echo $mensagem- 
>getHeaderLine( 'authorization'); 
// Vai retornar: AbcDef12340% 


echo $mensagem- 
>getHeaderLine( 'AUTHORIZATION' ); 
// Vai retornar: AbcDef1234@# 


$mensagem = $this->mensagem- 
>withHeader('Authorization', '1234567890abcdef !@$'); 

echo $mensagem- 
>getHeaderLine('authorization' ); 

// Vai retornar: 1234567890abcdef ! @$ 


} 


Como podemos ver no exemplo anterior, apesar de os 
cabecalhos serem recuperados independentemente do 
tipo da escrita, sem diferenciar letras maiúsculas e 
minúsculas, o nome original DEVE ser mantido pela 
aplicação quando for recuperado por meio do método 
getHeaders() . 


Os cabeçalhos também podem possuir múltiplos valores 
que podem ser definidos e recuperados de maneira 
simples e sem dor de cabeça. Isso se dá por meio de uma 
instância de Psr\Http\Message\MessageInterface Que nos 
disponibiliza dois métodos, sendo eles: getHeaderLine() e 
getHeader() , Sendo que o metodo  getHeaderLine() 
retorna os valores contidos dentro do cabeçalho em 


formato de string, já o método getHeader() retorna os 
valores contidos no cabeçalho em forma de array . Para 
simplificar o entendimento, vamos analisar o exemplo a 
seguir que demonstra o funcionamento na prática: 


<?php 
namespace App\Middleware\Authorization 
use PsriHttpiMessageWMessagelnterface; 


class AuthorizationMiddleware 


{ 


private $mensagem; 


public function _ construct(Messagelnterface 
$mensagem) 


{ 


$this->mensagem = $mensagem; 


public function defineHeaderValues() 
{ 
$mensagem = $this->mensagem- 
>withHeader ('authorization', 'Bearer AbcDef12340%') 
->withAddedHeader ( 'authorization', 
'Bearer 1234567890' ) 


$cabecalhoString = $mensagem- 
>getHeaderLine('authoriation'); 

//Retorna 'Bearer AbcDef1234@#, Bearer 
1234567890' 


$cabecalho = $mensagem- 
>getHeader('authorization' ); 

//Retorna ['Bearer AbcDef1234@#', ‘Bearer 
1234567890' | 


} 


Conforme podemos ver, definimos dois valores para um 
mesmo cabeçalho e os recuperamos de duas formas 
diferentes, em forma de array e em forma de string . 
Uma observação muito importante a ser considerada é 
que nem todos os valores podem ser concatenados 
usando uma vírgula (por exemplo, Set-Cookie ). Quando 
for trabalhar com esses cabeçalhos, a aplicação DEVE 
confiar no método  getHeader() que está contido na 
interface Psr\Http\Message\MessageInterface para obter 
esses cabeçalhos com multiplos valores. 


Em requisições, o cabeçalho do host espelha o 
componente de host do URI (Uniform Resource Identifier 
ou Identificador de Recursos Universal, em português), 
assim como o host utilizado ao estabelecer a conexão 
TCP (Transmission Control Protocol ou Protocolo de 
Controle de Transmissão). No entanto, a especificação do 
HTTP permite que o cabeçalho de host seja diferente de 
cada um dos dois. As aplicações DEVEM tentar definir o 
cabeçalho de host de um URI se nenhum cabeçalho dele 
for definido. Por padrão, o método withuri() definido na 
interface Psr\Http\Message\RequestInterface substituirá O 
pedido retornado com um cabeçalho de host 
correspondente ao componente do host passado. 


Você poderá optar por preservar o estado original do 
cabeçalho do host passando true para o segundo 
parâmetro do método withuri() . Quando esse parâmetro 
é definido como true , o pedido retornado nao atualizará 
o cabeçalho do host retornado pela mensagem, a menos 
que ela não possua nenhum cabeçalho de host definido. 


Streams (Fluxos) 


As mensagens HTTP consistem em uma linha inicial 
(método), cabeçalhos e um corpo, sendo que o corpo de 
uma mensagem HTTP pode possuir tamanhos variados 
desde muito pequeno a extremamente grande. Ao tentar 
representar o corpo de uma mensagem como uma 
string , por exemplo, a aplicação facilmente consome 
mais memória do que o necessário. Isso ocorre porque o 
corpo dessa mensagem deve ser armazenado 
completamente na memória. A tentativa de armazenar o 
corpo de uma requisição ou resposta na memoria 
impediria que o uso dessa solução fosse possível, pois 
trabalhar com esse tipo de implementação afetaria a 
performance da aplicação quando fôssemos trabalhar 
com grandes corpos de mensagens. 


A interface pPsr\Http\Message\StreamiInterface é utilizada 
para ocultar os detalhes da implementação quando um 
determinado fluxo de dados é lido ou escrito. Além disso, 
essa interface expõe diversos métodos que permitem que 
os fluxos sejam lidos, escritos e percorridos de forma 
eficaz. Os streams (fluxos) expõem seus recursos 
utilizando 3 métodos: isReadable() , iswritable() € 
isseekable() , cada um pode ser utilizado para determinar 


se um fluxo de dados é capaz de atender a seus 
requisitos ou não. 


Cada instância do stream (fluxo de dados) terá diversos 
recursos, como somente para leitura, somente para 
gravação ou para leitura/gravação. Também pode permitir 
acesso aleatório ou apenas acesso sequencial, como um 
fluxo de dados baseado em socket (soquete). Por fim, a 
interface  Psr\Http\Message\StreamInterface define um 


metodo _ tostring() para simplificar, recuperar ou emitir 
todo o conteúdo do corpo da mensagem de uma única 
vez. 


Ao contrário das interfaces de requisição 
Psr\Http\Message\Requestinterface e resposta 
Psr\Http\Message\ResponseInterface , a interface 

Psr\Http\Message\StreamInterface não é um modelo de 
imutabilidade, ou seja, em casos em que um fluxo real do 

PHP é empacotado, a imutabilidade é impossivel de ser 

aplicada, bem como em qualquer código que interage com 

o recurso, podendo alterar seu estado (incluindo posição 

do cursor, conteúdo etc.). 


É recomendado que as aplicacóes utilizem fluxos somente 
leitura para requisições efetuadas do lado do servidor e 
respostas do lado do cliente. Além disso, as aplicações 
consumidoras DEVEM estar cientes de que a instância 

Psr\Http\Message\StreamiInterface PODE ser mutável 
podendo alterar o estado da mensagem. 


Solicitar destinos e URIs 


As mensagens de solicitação contêm um pedido-alvo 
como segundo segmento da linha de solicitação, sendo 
que o destino pode ser alguma das seguintes formas: 


e origin-form - Se presente na string de consulta, é 
chamado de URL (Uniform Resource Locator, ou 
Localizador Padrão de Recursos, em português) 
relativo. Geralmente, as mensagens transmitidas por 
TCP são de origem e os dados de esquema e 
autoridade geralmente só estão presentes por meio 
de variáveis CGI (Common Gateway Interface). 


e absolute-form - Consiste no esquema, autoridade 
( [user-info@]host[:port] , onde os itens entre 
colchetes são opcionais), caminho (se presente), 
string de consulta (se presente) e fragmento (se 
presente). Isso geralmente é chamado de URI 
absoluto e é a única forma para especificar um URI. 
Essa forma é usada ao fazer solicitações para 
Proxies HTTP, por exemplo, em um ambiente 
corporativo em que existe proxy configurado, 
restringindo o acesso. 

e authority-form - Consiste apenas na autoridade, é 
normalmente usado apenas em solicitações 
CONNECT para estabelecer uma conexão entre um 
cliente HTTP e um servidor de proxy. 

e asterisk-form - Consiste unicamente na string * e 
é utilizado com o método options para determinar 
as capacidades gerais de um determinado servidor 
da Web. 


Além desses pedidos-alvo, ou metas de solicitação, há 
algumas vezes em que um URL efetivo pode ser 
encontrado separado da segmentação da solicitação. 
Esse URL efetivo não é transmitido em uma mensagem 
HTTP, mas é utilizado para determinar o tipo de protocolo 
que será utilizado ( http/https ), a porta e o nome do host 
para fazer a requisição. 


O URI efetivo é representado pela interface 
Psr\Http\Message\UriInterface , que disponibiliza métodos 
para interagir com diversas partes do URI, o que eliminará 
a necessidade de análise repetitiva. Além disso, 
especifica um método | tostring() para que seja 
possível converter o objeto URI em uma representação 


em formato de string. 


Ao recuperar o pedido-alvo com o método 

getRequestTarget() , por padrão, o método utilizará o 
objeto URI e extrairá todos os componentes necessários 
para construir o formulário de origem - este é o pedido- 
alvo mais comum. Caso seja necessário que um usuário 
final utilize uma das outras formas, ou se o usuário 
desejar substituir o destino da solicitação, é possível fazer 
essa alteração utilizando o método withRequestTarget() . 
A chamada desse método não vai afetar o URI, pois ele é 
retornado através do método geturi(). 


Vamos analisar um exemplo em que o usuário efetua uma 
solicitação usando o formulário de asterisco para um 
determinado servidor: 


<?php 
namespace App\Middleware\Authorization 
use Psr\Http\Message\RequestiInterface; 


class AuthorizationMiddleware 


{ 
private $request; 
public function __construct(RequestInterface 
$request ) 


{ 
$this->request = $request- 
>withMethod( 'OPTIONS' ) 
->withRequestTarget('*' ) 
->withUri(new Uri( 'https: //www. php- 
fig.org/')); 
} 


} 


O resultado obtido dessa alteração seria semelhante ao 
mostrado a seguir: 


OPTIONS * HTTP/1.1 


Caso necessário, o cliente HTTP pode utilizar o URL 
efetivo obtido através do método geturi() para definir o 
protocolo, o hostname e a porta a ser utilizada. O cliente 
HTTP DEVE ignorar os valores contidos nos métodos 

getPath() €  getQuery() presentes na interface 

Psr\Http\Message\UriInterface e utilizar o valor obtido 
através do método getRequestTarget() , que por padrão 
concatena os valores obtidos nos métodos anteriormente 
citados ( getPath() € getQuery() ). 


Os clientes que optarem por náo fazer a implementacáo 
de uma ou mais das 4 formas de pedido-alvo, deveráo, 
mesmo assim, utilizar o método  getRequestTarget() 
Esses clientes devem rejeitar as metas de solicitação 
porque eles náo suportam e NAO DEVEM retroceder nos 
valores obtidos através do método geturi() . 


A interface Psr\Http\Message\RequestInterface 
disponibiliza métodos para recuperar o destino da 
solicitação ou criando uma nova instância com o destino 
fornecido. Por padrão, caso o destino da solicitação não 
seja especificamente composto, então o método 
getRequestTarget() retornará o formulário de origem do 
URI composto, ou / se nenhum URI for composto. 


O método withRequestTarget ($requestTarget) é 
responsável por criar uma nova instância com a 
solicitação de destino especificada, permitindo que os 


desenvolvedores criem mensagens de solicitação que 
possam representar as outras três formas de solicitação 
de destino (formulário absoluto, formulário de autoridade e 
formato asterisco). Quando utilizada, a instância de URI 
composta ainda pode ser utilizada, principalmente em 
clentes que requerem a criação da conexão com o 
servidor. 


Requisições do lado do servidor 


A interface Psr\Http\Message\RequestiInterface fornece 
uma representação geral de uma solicitação de uma 
mensagem HTTP, porém essas solicitações precisam de 
um tratamento adicional do lado do servidor. O 
processamento do lado do servidor precisa levar em 
consideração a CGl e ainda a abstração do PHP por meio 
da extensão de CGI. O PHP fornece uma simplificação 
em torno do empacotamento de entrada por meio de 
variáveis superglobais, como: 


e  $_COOKIE - Desserializa e concede acesso 
simplificado aos cookies HTTP. 

e $ GET - Desserializa e concede acesso simplificado 
aos parâmetros da string de consulta. 

e $ post - Desserializa e concede acesso simplificado 
aos parâmetros enviados via método post do 
HTTP. 

e $ FILES - Provê metadados que são serializados ao 
fazer uploads de arquivos. 

e $ SERVER - Concede acesso a variáveis de ambiente 
CGI/SAPI, que incluem o método de solicitação, o 
esquema de solicitação, o URI de solicitação e os 
cabeçalhos. 


A interface Psr\Http\Message\ServerRequestInterface 
estende a interface = Psr\Http\Message\RequestInterface 
para que seja possível obter uma abstração envolvendo 
essas variáveis superglobais, ajudando a reduzir o 
acoplamento junto a essas variáveis pelos clientes. Além 
disso, incentiva e promove a capacidade de testar a 
solicitação dos clientes. A solicitação do servidor fornece 
uma propriedade adicional chamada attributes para 
permitir aos clientes a capacidade de introspecção, 
decomposição e combinação da solicitação contra regras 
específicas da aplicação como: caminho, esquema, host 
etc. A solicitação do servidor também pode fornecer 
mensagens entre vários pedidos. 


Upload de arquivos - A interface 

Psr\Http\Message\ServerRequestInterface especifica um 
método para recuperar uma árvore de arquivos 
decorrentes de uploads em uma estrutura onde cada folha 
é uma instância de Psr\Http\Message\UploadFileInterface . 
É importante ressaltar que a variável superglobal $ FILES 
possui alguns problemas ao lidar com arrays de entradas 
de arquivos, por exemplo, se a aplicação enviar um array 
de arquivos contendo uma chave chamada arquivos e 
submetendo $arquivos[0] e $arquivos[1] , teremos a 
seguinte saída dada pelo PHP. 


array( 
'arquivos' => array( 
'name' => array( 
O => 'file0.txt', 
1 => 'filei.html', 


'type' => array( 
O => 'text/plain', 


1 => 'text/html', 


Quando, na verdade, o esperado seria algo como: 


array( 
'arquivos' => array( 
O => array( 
'name' => 'file0.txt', 
'type' => 'text/plain', 
EP wa 
Ya 


1 => array( 
'name' => 'filei.html', 
'type' => 'text/html', 
EEY 


Os desenvolvedores precisam conhecer o detalhe dessa 
implementação da linguagem PHP e assim escrever um 
código que possa reunir os dados de um upload em 
específico. Além disso, há cenários em que $_FILES não 
é preenchido: 


e Quando o método HTTP não é Pposr; 
e Quando estiver utilizando teste de unidade; 
e Quando o ambiente não for SAPI. 


Nesses casos, os dados terão que ser distribuídos de 
maneira diferente, por exemplo: 


e Um processo pode tentar analisar o corpo da 


mensagem para descobrir os uploads de arquivos. 
Em alguns casos, a aplicação pode não gravar os 
uploads de arquivos no sistema de arquivos, mas 
podem colocá-los num fluxo para reduzir o uso da 
memória, E/S (Entrada e Saída) e armazenamento. 

e Durante os testes de unidade, os desenvolvedores 
precisam simular os metadados de upload de 
arquivo para validar e verificar diferentes cenários. 


O método  getuploadedrFiles() fornece uma estrutura 
padronizada para a aplicação, sendo que é esperado que: 


e Todas as informações para um determinado upload 
de arquivo sejam agregadas e usadas para popular 
a instância de 
Psr\Http\Message\UploadedFileInterface . 
e Recriar a estrutura da arvore, sendo que cada folha 
é uma instância de 
Psr\Http\Message\UploadedFileInterface para um 
local determinado na arvore. 


A estrutura da arvore referenciada deve imitar a estrutura 
de nomenclatura na qual os arquivos foram submetidos. 
Veja o exemplo a seguir que demonstra a estrutura 
utilizando $ FILES: 


array( 
“php field' => array( 
'tmp_name' => 'phpUelOru', 
'name' => 'php-logo.png', 
'size' => 10586, 
'type' => 'image/png', 
'error' => 0, 


Agora veja como ficaria utilizando o metodo 
getUploadedFiles() : 


array ( 
'php field' => //Instancia de UploadFilelnterface 


), 
) 


Em alguns casos, você pode definir um array de 
arquivos, mas nesse caso a implementação da 
especificação deve agregar todas as informações 
relacionadas ao arquivo de acordo com o indice fornecido, 
Isso porque $_FILES acaba saindo da sua estrutura 
convencional em alguns casos. Como os dados dos 
arquivos enviados são derivados de $_FILES OU do corpo 
do pedido, o método withUuploadedFiles() também está 
disponível na interface 

Psr\Http\Message\UploadedFileInterface , permitindo a 
delegação da padronização para um outro processo. Além 
disso, a interface disponibiliza métodos que garantem que 
as operações funcionarão independentemente do 
ambiente: 


e O método moveTo($targetPath) é disponibilizado 
como uma alternativa recomendada e segura para 
realizar chamadas através do método 

move uploaded file() diretamente no arquivo 
temporário. As implementações vão detectar a 
operação correta para ser utilizada conforme o 
ambiente. 

e O método getstream() retornará uma instância de 

Psr\Http\Message\StreamInterface . Em ambientes 
que não sejam SAPI, a proposta é realizar uma 
análise dos arquivos de upload individuais em 


php://temp . Em alguns casos, o arquivo de upload 
não está presente, portanto, o método getstream() 
é garantido para manter a funcionalidade 
independentemente do ambiente. 


Após termos passado por toda a PSR-7, não podíamos 
deixar de especificar as interfaces que fazem parte desse 


pacote, então vamos conferi-las a seguir: 


PsriHttpiMessageMessageInterface 


<?php 


namespace Psr\Http\Message; 


interface MessageInterface 


{ 


} 


public 
public 
public 
public 
public 
public 
public 
public 
public 
public 
public 


function 
function 
function 
function 
function 
function 
function 
function 
function 
function 
function 


getProtocolVersion(); 
withProtocolVersion($version); 
getHeaders(); 

hasHeader ($name); 

getHeader ($name); 
getHeaderLine($name) ; 
withHeader($name, $value); 
withAddedHeader($name, $value); 
withoutHeader ($name); 
getBody(); 
withBody(StreamInterface $body); 


Psr\Http\Message\RequestInterface 


<?php 


namespace Psr\Http\Message; 


interface RequestInterface extends MessageInterface 


public 
public 
public 
public 
public 
public 


function 
function 
function 
function 
function 
function 


getRequestTarget(); 
withRequestTarget($requestTarget ); 
getMethod(); 

withMethod($method); 

getUri(); 

withUri(UriInterface $uri, 


$preserveHost = false); 


} 


Psr\Http\Message\ServerRequestinterface 


<?php 


namespace Psr\Http\Message; 


interface ServerRequestInterface extends 


{ 


public 
public 
public 
public 
public 
public 
public 


function 
function 
function 
function 
function 
function 
function 


$uploadedFiles); 


} 


public 
public 
public 
public 
public 
public 


function 
function 
function 
function 
function 
function 


Requestinterface 


getServerParams(); 
getCookieParams(); 
withCookieParams(array $cookies); 
getQueryParams(); 
withQueryParams(array $query); 
getUploadedFiles(); 
withUploadedFiles(array 


getParsedBody(); 
withParsedBody ($data); 
getAttributes(); 
getAttribute($name, $default = 
withAttribute($name, $value); 
withoutAttribute($name); 


null); 


Psr\Http\Message\ResponselInterface 


<?php 


namespace Psr\Http\Message; 


interface ResponseInterface extends MessageInterface 


{ 
public function getStatusCode(); 


public function withStatus($code, $reasonPhrase = 
2); 
public function getReasonPhrase(); 


3 
Psr\Http\Message\Streaminterface 
<?php 

namespace Psr\Http\Message; 
interface StreamInterface 


{ 


public function __toString(); 


} 


Psr\Http\Message\UrilInterface 


public function close(); 


public 
public 
public 
public 
public 
public 
public 
public 
public 
public 
public 
public 
public 


<?php 


function 
function 
function 
function 
function 
function 
function 
function 
function 
function 
function 
function 
function 


detach(); 
getSize(); 


tell(); 
eof(); 


isSeekable(); 


seek($offset, Swhence = SEEK SET); 


rewind(); 

iswritable(); 
write($string); 
isReadable(); 
read($length); 
getContents(); 
getMetadata($key = null); 


namespace Psr\Http\Message; 


interface Urilnterface 


{ 


public 
public 
public 
public 
public 
public 
public 
public 
public 
public 


null); 


} 


public 
public 
public 
public 
public 
public 


function 
function 
function 
function 
function 
function 
function 
function 
function 
function 


function 
function 
function 
function 
function 
function 


getScheme(); 
getAuthority(); 
getUserInfo(); 
getHost(); 
getPort(); 
getPath(); 
getQuery(); 
getFragment(); 
withScheme($scheme); 


withUserInfo($user, $password = 


withHost($host); 
withPort($port); 
withPath($path); 
withQuery($query); 
withFragment ($fragment); 
— RGString( ); 


Psr\Http\Message\UploadedFileInterface 


<?php 


namespace Psr\Http\Message; 


interface UploadedFileInterface 


{ 


public 
public 
public 
public 
public 


function getStream(); 
function moveTo($targetPath); 
function getSize(); 

function getError(); 


function 


getClientFilename(); 


public function getClientMediaType(); 
} 


Com isso, nos chegamos ao final da PSR-7, que define 
interfaces em comum para que a troca de mensagens 
HTTP se torne mais simples. Não é uma regra tão simples 
de ser seguida e é preciso ter muita atenção no momento 
em que estiver implementando a PSR-7 em sua 
aplicação. São muitos detalhes que devem ser seguidos 
para que o seu código possa estar em conformidade com 
essa PSR. O que foi descrito aqui pode ser visto com 
mais detalhes no link https://www.php-fig.org/psr/psr-7/. 
Na próxima seção vamos conhecer a PSR-15. 


16.2 PSR-15 (HTTP Server Request Handlers) 


Com o principal objetivo de fornecer interfaces comuns 
para a manipulação das solicitações HTTP, os Handlers 
(manipuladores) São essenciais em qualquer aplicação 
Web. O código do lado do servidor recebe uma 
solicitação, que é processada, e então é gerada uma 
resposta que pode ser repassada para outra aplicação ou 
não. 


Os Handlers em APIS podem ser considerados como 
estruturas que trabalham sobre o protocolo HTTP, sendo 
que recebem uma requisição/solicitação de entrada e 
geram uma resposta como saída, que pode ou não ser 
repassada para outros Handlers. Por exemplo, para 
realizar a autenticação de um usuário, teriamos algo como 
um Handler de autenticação que recebe as credenciais do 
usuário. Se os dados estiverem corretos, então ele poderá 


passar para o próximo Handler, indicando que a 
autenticação foi bem-sucedida e está pronta para receber 
autorização para acessar os recursos permitidos para 
aquele usuário. Para entendermos melhor o 
funcionamento dos Handlers, veja o exemplo a seguir que 
demonstra o seu funcionamento dentro de uma API: 


AuthenticationMiddleware 


Nieto 

(Solicitação Requisição) ) Aplicação esias Se o > 

| Á i 
Y 4 


Figura 16.1: Funcionamento Middlewares 


Conforme mostrado na imagem anterior, nos temos duas 
camadas de Middlewares/Handlers. O 

AuthenticationMiddleware recebe a requisição. Após 
receber a requisição é realizada uma verificação que pode 
ou não conceder o acesso ao usuário. Em caso afirmativo, 
os dados da solicitação são passados para o próximo 
Middleware/Handler, que no caso do exemplo é o 
AuthorizationMiddleware . 


O AuthorizationMiddleware é responsável por verificar se 
O Usuário possui autorização para acessar um 


determinado recurso do sistema, se sim, então os dados 
são enviados para a camada da aplicação para continuar 
O processamento. Podemos ter quantos 
Middlewares/Handlers forem necessários, tudo vai 
depender da sua aplicação. 


Vamos conhecer a seguir as regras que definem essa 
PSR para entendermos como aplicá-la de forma coesa. 


Request Handlers (Manipuladores de 
Requisição/Solicitação) 


É um componente individual que realiza o processamento 
de uma solicitação e consequentemente gera uma 
resposta, conforme definida pela PSR-7. Um Request 
Handler PODE lançar uma exceção caso as condições da 
solicitação/requisição forem impedidas de produzirem 
uma resposta, porém, o tipo de exceção não está definido. 
Os Requests Handlers que utilizam esse padrão DEVEM 
implementar a interface 
Psr\Http\Server\RequestHandleriInterface . 


Middleware 


E um componente individual que trabalha junto com 
outros Middlewares/Handlers durante o processamento de 
uma requisição/solicitação e gera uma resposta como 
saida, conforme definida pela PSR-7. Um 
Middleware/Handler PODE criar e retornar uma resposta 
sem que haja a delegação para um Request Handler 
desde que as condições necessárias sejam atendidas. 
Para utilizar este padrão, os middlewares DEVEM 
implementar a interface 
Psr\Http\Server\MiddlewareInterface . 


Generating Responses (Gerando Respostas) 


É RECOMENDADO que qualquer manipulador 
(Handler/Middleware) ou de solicitação/requisição 
(Request) que gere uma resposta componha um modelo 
de resposta baseado na PSR-7, implementando a 
interface Psr\Http\Message\ResponseInterface ou até 
mesmo uma Factory (fábrica) capaz de gerar uma 
instância de Psr\Http\Message\ResponseInterface . Assim 
evita-se dependência de uma implementação específica 
de mensagem HTTP. 


Handling Exceptions (Tratamento de Exceções) 


É RECOMENDADO que qualquer aplicação que utilizar o 
Middleware/Handler inclua um componente responsável 
por realizar a captura das exceções e as converta em 
respostas. Este Middleware DEVE ser o primeiro 
componente a ser executado e envolver todo o 
processamento adicional para garantir que uma resposta 
seja sempre gerada. 


Essas são as regras que a PSR-15 define, não é nada 
complicado e é tecnicamente muito simples de 
implementar em sua aplicação. A maioria dos frameworks 
e microframeworks já possui suporte a essa PSR. Basta 
você desenvolver a lógica da sua aplicação e seguir as 
regras conforme estipuladas. 


A seguir, vamos conhecer as interfaces que fazem parte 
desse pacote, são elas: 


Psr\Http\Server\RequestHandlerInterface - Essa interface 
DEVE ser implementada por componentes de 


Middleware/Handler compatíveis. 
<?php 
namespace Psr\Http\Server; 


use Psr\Http\Message\ResponselInterface; 
use Psr\Http\Message\ServerRequestInterface; 


interface RequestHandlerInterface 


{ 


public function handle(ServerRequestInterface 
$request): ResponseInterface; 


} 


Psr\Http\Server\MiddlewareInterface - Essa interface 
DEVE ser implementada pelo componente de 
Middleware/Handler compatível. 


<?php 
namespace Psr\Http\Server; 


use Psr\Http\Message\ResponselInterface; 
use PsriHttpiMessageNServerRequestInterface; 


interface MiddlewareInterface 


{ 


public function process(ServerRequestInterface 
$request, RequestHandlerInterface $handler): 
ResponseInterface; 


} 


Conforme você pôde ver, são duas interfaces bem 
simples que não possuem muitos métodos, mas definem 
perfeitamente os conceitos de Middlewares/Handlers e 
manipuladores de solicitacáo/requisicáo para que sua 


aplicação possa ou não delegar os dados para um outro 
Middleware/Handler. 


Conclusão 


Vimos aqui os conceitos, regras e aplicações das PSRs 7 
e 15 que visam padronizar como tratamos nossas 
requisições e como delegar a requisição para outros 
Handlers até que um Handler possa ser capaz de realizar 
o tratamento adequado. 


Tudo isso é feito por meio do conjunto de interfaces que 
fazem parte de cada um dos pacotes. Cada interface 
disponibiliza métodos que tratam de uma determinada 
tarefa. 


Essas PSRs são muito utilizadas em sistemas Web com o 
PHP e não poderiam ficar de fora deste livro. É importante 
conhecê-las, já que elas faciltam e muito a vida dos 
desenvolvedores. 


CAPÍTULO 17 
Conclusao 


E isso ai meu amigo, chegamos ao final do livro e espero 
que vocé tenha gostado do que vimos durante todos 
esses capitulos. 


O intuito desta obra foi demonstrar como podemos 
desenvolver uma aplicação REST com o Zend 
Expressive, que é um poderoso microframework 
desenvolvido pela Zend. Junto a isso, realizamos a 
integração dele com o ORM Doctrine para trabalharmos 
na camada de abstração de dados proveniente do banco 
de dados. 


Como você pôde ver, as coisas no Zend Expressive 
devem ser bem explicitadas, ou seja, criou um Handler? 
Registre esse Handler. Criou um serviço? Então, registre 
esse serviço. Durante todos esses capítulos, vimos desde 
os conceitos de API, frameworks, microframeworks até 
aos conceitos das PSRs 7 e 15. 


Geramos entidades automaticamente utilizando o 
Doctrine, criamos os repositórios dessas entidades, 
criamos diversos Handlers, Factories, serviços, definimos 
as rotas da nossa aplicação e muito mais. 


Vale ressaltar que muitas melhorias podem ser feitas no 
código, como a utilização de try cach para capturar as 
exceções de erros, criação de Handlers para filtrarem e 
validarem os dados enviados pela aplicação cliente, 
dentre outras. 


Nesta obra, foram demonstrados apenas os conceitos 
para desenvolver com o Zend Expressive e, como você 
pôde ver, não é difícil, mas sim, trabalhoso. Se você já 
estiver habituado com o Zend Framework, então você não 
verá muita diferença no trabalho. Mas se você estiver 
vindo de um framework como o Laravel, então verá que 
as coisas por aqui realmente são mais trabalhosas, mas 
nada que uma questão de costume e adaptação não 
resolva :). 


Caso você tenha tido dúvidas, críticas, sugestões você 
poderá mandar um e-mail para 
jhones.developer@gmail.com OU me adicionar em sua rede 
do LinkedIn  (https://www.linkedin.com/in/jhones-dos- 
santos-clementino-91a90256/), que ficarei feliz em lhe 
responder e trocar conhecimentos. 


Abraços e até a próxima! 
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